"Radosavljevic, Branko" <branko.radosavljevic@bankofamerica.com> writes:
I have a newbie question about using Boost.Thread to invoke a memory fence operation. What are the memory fence guarantees associated with the synchronization concepts in Boost.Thread?
My specific use case involves one writer and several readers. For example, something like:
bool available = false; int value;
// Writer thread value = getValue(); available = true;
// A reader thread while (!available) yield(); doSomething(value);
In other words, the write to available should have release semantics, and the read from available should have acquire semantics. I realize I can use platform-specific commands, but I'd rather not. I assume that if I want to use Boost.Thread, I'll need to use a mutex, but I don't see any discussion of memory fence issues in the documentation.
Anthony Williams [anthony.ajw@gmail.com] writes:
If you use a mutex to protect "available", then the appropriate semantics will be in place.
Zeljko Vrba [zvrba@ifi.uio.no] writes:
POSIX mutexes gurantee that proper fences will be applied at the right spots. My guess is that the same holds also on Windows, but you should check with the documentation. (If you're using x86/x64, all atomic instructions are also acquire/release fences.)
Thanks, Anthony and Zeljko. It appears that any mutex lock and unlock will apply the correct memory fences, so that for this purpose only, the writer and readers can use separate mutexes (ie, guaranteed no contention). At least, I verified this for Windows. However, the separate issue of ensuring that the read of "available" is not corrupt, in case there's a simultaneous write, would require that the reader and writer use the same mutex. That's the approach that I'll use. Thanks again, Branko Any information contained in or attached to this e-mail is intended solely for the use of the intended recipient(s), is confidential and may contain information that is legally privileged. If you are not an intended recipient of this e-mail, please notify the sender of the delivery error and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this e-mail is expressly prohibited. See http://www.bankofamerica.com/emaildisclaimer (if this link is not clickable, please copy and paste the link into your browser address bar) for further important information on confidentiality, the risks inherent in electronic communication (including the possibility that e-mail messages cannot be guaranteed to be secure or free of errors or viruses), some of our policies regarding transactions and pricing and certain other matters.