From: Dan W. (danw_at_[hidden])
Date: 2004-01-01 19:00:19
Pavel Vozenilek wrote:
> 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.)
Wasn't aware of the debate; but if I remember correctly,
interlocked_exchange must be supplied with a volatile...
seems to me interlocked_exchange() wouldn't work if volatile did not
work as advertised. Maybe the debate is about cross-platform guarantees?
> 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.
Thank you, I'm in the process of looking at it. I coded my own circular
buffer, years ago. This double_buffer would be complementary, though,
for use in situations where the intent is not to allow an indeterminate
amount of delay in consumer response, but simply to implement the
minimum buffering that allows producer and consumer to execute in
paralled, in MP platforms; but where the buffers would typically be
large data structures of fixed size, and where bi-directional
communication via such structures might be desirable.
A circular buffer equivalent implementation would be one where there are
two circular, 2-deep, buffers of pointers to data structures that are
only allocated/deallocated once; and in which pair of circular buffers
there is a fixed total number, two, of such pointers.
> AFAIK shared_ptr<> uses interlocked_exchange() for Win32, mutex elsewhere.
> The shared_ptr documentation contains performance benchmarks.
Yes, I'm looking at it. I might have to code my own, stripped down,
non-thread-safe version of shared_ptr for double_buffer's use, as the
intended use is between two threads, and the shared_ptr's used on each
side are independent of each other, so that thread safety isn't needed.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk