As an occaisonal user and non-expert user of memory fencing, I'd like to see a portable implementation in boost as a step to capturing some memory semantics. Peter Dimov suggested he like Alexander's unidirectional model. I'm guessing at what he means... I'm not too fond of the acquire, release naming. I'd prefer something simpler to understand like publish and subscribe, though on some platforms this seems to have specific meaning... e.g. sparc. Any suggestions? What about a simple facade like: boost::memory::complete_reads(); boost::memory::complete_writes(); boost::memory::complete_all(); Simpler to understand but perhaps a bit misleading...? Or should it be kept normal with respect to common nomenclature: boost::synch::fence::load(); boost::synch::fence::store(); boost::synch::fence::full(); As a second point. On ia32, quite a popular platform, locking and unlocking mutexes has full fence semantics. On Sparc too. This is not the case on others. I'd like to be able to write optimal portable code for the case where I want a fence along with unlocking a mutex. I can think of a few courses of action: 1. full fence semantics required by mutex unlock and/or lock - overly costly and dumb I think 2. adjacent lock_unlock fence ops that may or may not be null ops boost::synch::fence::unlock_and_full() boost::synch::fence::lock_and_load() ;-) - seems awkward, especially for ia32 where they are no-ops 3. special lock and unlock ops for each case... yuck 4. a policy for a mutex that is used when locked and unlocked 5. forget it cause in practice you don't need it very often at all - probably true, but I have such a thing i use to speed up some stuff on sparc and ia32 where i have a very cheap is_empty check and don't care about other costs. 4 seems the most tolerant way... thoughts? If we can get some agreement, I'll put together a simple ia32 implementation for gcc and msvc with a short doc. Matt.