From: Pavel Vozenilek (pavel_vozenilek_at_[hidden])
Date: 2003-12-31 13:23:57
"Dan W." <danw_at_[hidden]> wrote
> Re.: "thread safety" --without mutexes:
> >Is it safe against ... CPU cache effects?
> I believe so, given that (what I call) safety is achieved in the logic of
> moving tokens (pointers) in T * volatile arr; which I declared
> precisely to get around cache effects (though, looking at it again I
> if I shouldn't have written "T volatile * arr;"... No, I think it's
> right; it is the pointers stored in the array that need to be volatile.)
Whether or not volatile protects data accessed from multiple threads is
topic of heated usenet debates. It is believed they do not, generally. (I am
no expert but got curious whether there's a way.)
In Boost files section you can find circular_buffer library (ready for
review., http://groups.yahoo.com/group/boost/files/, file
circular_buffer_v3.5.zip). I was thinking whether together with
'synchronized' it may be used just for consumer-producer problem.
> >Is it because shared_ptr<> uses mutex inside?
> I wasn't aware of this. Aren't mutexes infamous performance-wise? I read
> article in CUJ a year or more ago, the author was advising the use of
> interlocked_exchange() as an alternative to mutexes; though I'm aware
> is a platform specific facility; but I'd assume there'd be similar
> facilities in other platforms that could be all accessible via a portable
> library. I'm obviously too ignorant in this area to be posting
> thread-related solutions; though I'm sure all the thought I put into the
> synchronization code could not be just good for nothing. I'm worried
> about performance impact of a mutex in shared_ptr...
AFAIK shared_ptr<> uses interlocked_exchange() for Win32, mutex elsewhere.
The shared_ptr documentation contains performance benchmarks.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk