|
Boost : |
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[6]; which I declared
volatile
> precisely to get around cache effects (though, looking at it again I
wonder
> if I shouldn't have written "T volatile * arr[6];"... 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
an
> 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
this
> 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
though
> 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.
/Pavel
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk