Re: Thread safe array class
On Sep 12, 9:52 am, andreas.zetterst...@gmail.com wrote:
I'm implementing some different c++ classes which I want to be
thread safe. All these classes contain lists or arrays of some
kind. I'm using protected sections to make them thread safe.
Just to be 100% clear: what do you mean by "protected" sections?
("Protected" has a very definite meaning in C++, which has
nothing to do with threading. I presume you mean something to
do with locks or mutexs. The word "synchronization" would be a
better choice in that case, if only because it avoids the
ambiguity with the C++ concept.)
The question then is: how do you in a nice safe way pick
values out of the list?
What do you mean by "pick values out of the list"? You need a
lock to read or access the values in the list, at least if there
is a thread anywhere else which may access the list. The
simplest rule is to never allow a pointer, a reference or an
iterator to something in the list to escape a synchronized
block. This is extrodinarily constraining, but the actual rules
are complex (and depend on the container).
The easiest way is to have a pair of Lock, Unlock functions,
but this also presents a lot of ways of doing a misstake.
Say the list class has 5 functions, one to get the number of
items, one to get items one by one and 3 other functions. The
3 functions have their locks internally as per c++ design you
don't want other classes need to know anything about internal
structure of another class. The 2 other functions is the
problem. I would have to have external locks to lock them as
the number of items might change while going through the list
otherwise. 3 problems arise with that solution: you might
forget (or don't know that it's needed) to lock the list
before using it, you might forget to unlock the list while
done and you might deadlock against other list functions that
you didn't know were blocking too (or because you thought
external locks were needed there as well).
There are two distinct problems here. The first is accessing
individual members in the container. You can't return a
reference or a raw pointer to the element, since this would
allow unlocked access to it; in addition, some other actions on
the container (in another thread) might invalidate the pointer
or reference. For read only access, returning a copy is often a
valid solution. I've also used smart pointers in this case:
return a reference counting smart pointer to the element, which
frees the lock when the last reference disappears. (You can use
boost::shared_ptr for this---just provide an appropriate
deleter.)
The second problem is race conditions outside of the container.
The size() function returns the number of elements at the moment
it is called, but this can change at any point outside of the
function. The granularity of the locks the container can
provide is too low to be really useful. (This is, of course,
why the standard containers don't lock.) You could provide a
nested class which manages some sort of scoped lock for the
container, and require the client code to use this. If you
wanted to be double sure, you could even have the scoped lock
inform the container of its existance, and which thread held it,
and assert() in each function that it was called by this thread.
How to solve this in a nice way? I've been thinking of perhaps
supplying a list to a special function in the list class that then
transfers all the list data in the class to the supplied list and thus
having a copy that won't risk changing. This will take double the
memory and will require an extra loop through the data though.
There are really only two choices if client code needs to call
more than one function with a consistent state: either the
client code uses a private copy, or it holds a lock for the
entire duration. Since only the client code can know the
appropriate granularity of locking, only the client code can
manage the locks. There are very, very few cases where it makes
any sense to have the container itself manage locking.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34