Boost logo

Boost :

From: Dan W. (danw_at_[hidden])
Date: 2003-12-30 11:37:47

Pavel Vozenilek wrote:
>>Call create_double_buffer<my_buff_t>( new my_buff_t, new my_buff_t )
> This is exception unsafe, btw.

Aha, ok. I'll try to take responsibility for allocation and watch out for
exemptions. Thanks.

> Is this similar to 'synchronized' library:
> ?

I was just looking at synchronized.hpp. If I understand the code correctly,
synchronized aims to atomize access to a type. What my double_buffer class
aims to do is,
A) substitue for producer/consumer-type data flow between threads, where
one thread allocates memory and the other de-allocates it, as that is 1)
time consuming, and 2) problematic for some per-thread allocators. My code
re-uses two buffers which are allocated once; but it imposes the
restriction on both producer and consumer that they must let go of a buffer
before checking-out the other.
B) Implement such buffer exchange mechanism in a way that doesn't require
blocking of producer or consumer threads; --what I mean is that the
checkout_buff() and checkout_data() functions (and the release mechanism
via function call operator) can be called asynchronously.

> Can you please explain in detail how thread safety is reached without using
> mutexes? Is it because shared_ptr<> uses mutex inside? Is it safe against
> compiler optimizations and CPU cache effects?

Re.: "thread safety" --the term:
Please accept this excuse for my ignorance: C++ is my hobby; my line of
work is embedded systems using small microcontrollers, in Assembler. My
concept of thread-safety is probably much lower level than anyone-else's
around boost: I deal with interrupts. So, I'm not sure I used the term
correctly. If by 'thread safe' it is meant that any number of threads
could safely have producer or consumer access, that is NOT what I was
meaning to claim. The intended use of double_buffer is for *two* threads,
'producer' and 'consumer', to respectively call the functions meant for
each, namely 'checkout_buff()' and 'checkout_data()'. Creation of the
double buffer could be handled, I believe safely, by either, or yet another

Re.: "thread safety" --without mutexes:
Let me start from the last question

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

>Is it safe against compiler optimizations?
I believe it is, though this calls for a long answer; I'll try to present
just a small example of one consideration: In the reset() routine, which is
only used by double-buffer-implementation's ctor, so it can be thought as
part of it, and goes like (some line numbers added),

template< typename T > //reset
void db_impl<T>::reset()
     for(int i = 0; i < 6; ++i) arr[i] = 0;
1) arr[5] = pbuf2_;
2) arr[0] = pbuf1_;
3) if( arr[0] == 0 ) //see notes below
4) arr[0] = pbuf2_;
5) arr[5] = 0;

Lines 1) and 2) place the two buffers' tokens in the two waiting positions
for producer checkout. Even though pbuff1_ and pbuff2_ cannot be zero, I
check for zero in line 3) to make sure that the producer hasn't called
checkout in between the initializations of the two tokens. If it has, then
I move the token in the second waiting position to the first, lines 4) and
5). For the compiler to optimize away this check, it would have to infer
that pbuff1_ cannot be zero from an assertion to that effect in the calling
ctor, which I'm sure no compiler would go to such extent.
Similar reasonings apply to some of the post-checks I do in the checkout
functions. They would be at risk of a human programmer thinking that the
post-checks are unwarranted, but not at risk of compiler optimization,
simply because the compiler lacks enough info to optimize them.

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

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