|
Boost : |
From: Edd Dawson (lists_at_[hidden])
Date: 2008-01-07 14:40:47
Hi Kirit,
Kirit Sælensminde wrote:
> It isn't just interleaving that you're going to have problems with here.
> In these days of multi-cores and SMP with non-shared on-core caches
> you're also looking for visibility problems where a memory write doesn't
> appear for a thread on another core/processor -- something else you
> might be able to simulate, but it would be complex too.
That's an interesting idea, though I currently have absolutely no idea how I'd
implement that! I can't see any way of doing it without some of the funkier
meta-programming tricks of more dynamic languages.
One brain-fart in this general area is that compilers may do different (fewer)
kinds of optimisation if threading machinery is detected (AFAIK, this is how
pthreads is able to make certain guarantees in conjunction with a compiler).
This may have consequences for testing and correctness in general, too. Loads
and stores might get moved about by an optimiser looking at coroutine-threaded
code causing tests to fail when they'd pass with pre-emptive threading; an
assignment may get moved outside a lock()/unlock(), for example.
I don't know enough about this area to be able to reason particularly clearly,
however.
> Using co-routines is an interesting idea, but for the things that they
> will let you test formal proofs may not be any more work and may give
> more confidence than testing.
You might be right. But it sounds like too much "fun" not to try :)
If successful, it might also stand as a proof of concept for implementing the
boost::threads API on systems that don't have pre-emptive threads support, for
what it's worth.
Edd
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk