   volatile bool vs event
  Are there any advantages to using an unnamed win32 event (CreateEvent) over using a volatile bool?   
  Yes, when waiting for an event the O.S. will pause the thread and continue another thread (possibly another application), or put the processor in an energy-saving halting state when there are no more tasks. With a volatile bool you could end up with a situation where the processor 'spins' so it takes valuable execution time until another thread gets scheduled.Only for very short spin times a volatile bool can be more efficient because events do have an overhead.   ;  Just remember, you can't guarantee synchronization with a volatile bool unless you use the CMPXCHG instruction.   ;  I was thinking more along the line ofif(waitforsingleobject(Event, 0)){//do something}Compared withif(myeventbool){//do something}Are you saying it is safer to use an event over using a bool?   ;  It is emperically safer to use an atomic API event. Like mentioned above, the CPU could very well be stolen by the OS halfway through a bool assignment. Not a super big problem since it only really relies on one bit.. until you think that there's 8 of them, and the last bit may be the only one that doesn't get filled before the CPU moves on to another thread.All Win32 events are guaranteed to be atomic. Either it grants threads a little bit of extra CPU time to get the job done, or it simply blocks all threads waiting for that event and by-passes them continually until the initial thread finishes the "atomic" setting of the event. Either way, it's guaranteed by MS that it works, I can't see how Windows could be so stable if it didn't. ;)   ;  reminds me of Wrinting unmaintainable codeQuote:Use Spin LocksAvoid actual synchronization primitives in favor of a variety of spin locks -- repeatedly sleep then test a (non-volatile) global variable until it meets your criterion. Spin locks are much easier to use and more "general" and "flexible " than the system objects.This is just an entertaining quotation ;)   ;  Is writing to a bool not an atomic operation?   ;Quote:Original post by quantIs writing to a bool not an atomic operation?There are x86 instuctions to make it atomic, but I doubt the compiler would use them by default.   ;  Writing to a bool will be atomic.  It's test-and-set which usually isn't.Σnigma   ;  Individual writes and reads are always atomic given that:- They are entirely contained in one cache line (if your compiler pads structures to align variables, this should be guaranteed)- They are not larger than the maximum size the processor can write in a single instruction (generally the processor word size)As one person pointed out, you must use atomic primitives to atomically read a value, modify it, then write it back.   