On Fri, Sep 11, 2009 at 4:38 PM, Gottlob Frege
On Fri, Sep 11, 2009 at 11:55 AM, John Dlugosz
wrote: If that particular writing thread stalls (or crashes!?), the reader thread may have to wait "forever", even though other writes are finished and waiting.
Not impossible to handle, but something to keep in mind.
That's a general issue that is always present. If one thread is in the middle of some elaborate protocol "dance" with other threads, and throws an exception out of there (or just hangs), the other threads will be affected.
I see the particular issue here is fault-tolerance -- one worker fails, but others are still producing data. The area that is sensitive is just allocate the slot copy the fields in, being sure to copy the flag last.
I don't expect anything to go wrong when just copying PODS from one struct to another. But perhaps I should elaborate that this "critical region" should indeed be that simple: make the record a simple struct or single pointer, not something that is elaborate to construct/copy.
By the way, the other problem is priority inversion - if Thread 1 is trying to allocate/copy/flag, and thread 2 is spin waiting on that, but Thread 2 has higher priority (and they are on the same/only CPU) then you are deadlocked. Or does thread 2 sleep in the spin? Tony