Boost logo

Boost :

From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2005-04-27 20:35:27

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:


Simpler to understand but perhaps a bit misleading...?

Or should it be kept normal with respect to common nomenclature:


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::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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at