Paul
wrote: Synchronous cancellation may be simulated by setting a simple flag polled by the cancellable thread. (Appropriate memory barriers must be placed after setting and before polling the flag. In the absence of portable memory barrier facilities, one may protect the flag with a mutex, though that's annoyingly heavyweight.) However this does not
just out of curiousity, why do you think you need a memory barrier on a flag? you would have 1 writer and 1 reader... either the reader reads false or true, and once the writer has set it to true... thats it, the reader will read true on the next pass.
even if the reader is reading the same time as the writer is writing, and byte-sized memory writes are not atomic (which i think they are), then the read will still evaluate to true, which is what is desired anyway.
so theres no need for a mutex in this case? even if there were multiple writers, its a one-way flag set operation, all would be trying to set the flag to true if all were writing at the same time, so all would get the desired result?
Paul, When the flag has changed the memory semantics of your system maybe such that your cpu doesn't see the change for quite a while without memory barriers. If it changes, say flip flops between true and false (not relevant to your case above), then you could end up with different values everywhere at once which may be inconvenient to your programs correctness. HTH, Matt. matthurd@acm.org FWIW: Here is memory barrier definition I use on win32, though it is an inapproprite interface for generic consumption: /*___________________________________________________________ created: 2004-12-7 7:18 filename: fence.hpp author: Matt Hurd purpose: ____________________________________________________________*/ #ifndef fence_hpp_2004127 #define fence_hpp_2004127 namespace synch { struct fence { static void load () { __asm lfence; } static void store () { __asm sfence; } static void memory () { __asm mfence; } static void flush () { __asm cpuid; } }; } // namespace #endif