On Mon, 2014-06-16 at 09:18 +0800, Nor Jaidi Tuah wrote:
True - there is a few cases where volatile can be used (I know too little about security to say if using just volatile is ok from standard POV). I guess you could reformulate my question into - "in most you don't need volatile and many programmers use volatile as atomic despite it does not mean that. Are you sure that your use case is legitimate?".I have one use case which may not be legitimate academically (whatever that means), but in practice should be ok. I assume that access to a byte is always atomic and so I don't have to use a lock or other sync mechanisms. I think this is reasonable if my routine can tolerate cache delay (one thread already updating, another thread still using the old value). But I still need to tell the compiler to suppress its optimization, hence volatile.
In many cases "not legitimate academically" means "not according to C standard and may not work on current or future architectures with current or future compilers". On most architectures align access should be indeed atomic but I am not 100% sure about, for example, Alpha. Also note that load and store are atomic - not for example addition. Note however that the accesses are atomic but not synchronized[1]. Note that you don't need lock or sync - you just need to use an atomic. GLib has support for sequential consistent atomics by default and when you will have access to C11 compiler you will have proper access to other ordering starting with relaxed (no synchronization - only atomicity) ending with sequential consistency. Note that the atomics tend to be 'hard' to reason about once you go below sequential consistency as you have the memory synchronization relaxed - see this 3h talk about _basics_ of the C++11 memory model if you want to know more - http://channel9.msdn.com/Shows/Going +Deep/Cpp-and-Beyond-2012-Herb-Sutter-atomic-Weapons-1-of-2. Two things to know: - Most people got the requirements for reference counting wrong IIRC - IIRC There is a small error in explanation about fences vs. atomics (I'd have to goggle it again to find what exactly is the problem) Note that reasoning deal with memory _ordering_ not delay as the thread model allows infinite suspension of any thread, so the memory can be indeed delayed indefinitely. Best regards [1] Synchronized means if x and y are set to 0 and thread 1 sets first x and then y to 1 then thread 2 might read y == 1 and then x == 0. Atomic means that state of x and y are either 0 or 1. Note that x86 is rather strongly order architecture so you won't notice it in _most_ circumstances on that platform but you can get the reordering on for example arm. Programmers manual from processors should have a few pages in them stating the exact rules.
Attachment:
signature.asc
Description: This is a digitally signed message part