Re: mutexes and const_iterators
On 15 mar, 18:57, Paavo Helde <nob...@ebi.ee> wrote:
"Angus" <nos...@gmail.com> wrote
innews:frg7um$s14$1$8300dec7@news.demon.co.uk:
I am using a map which holds a list of client connections (to a
server). When a client connects a client gets added to the map and
also when a client disconnects.
In various parts of the code the map gets updated - the key is an int
and the value is a class.
As the map may be accessed by multiple threads I use a mutex to
control access - ie locking whenever an item is added or removed.
I have these questions:
1. Do I also need to lock if I just update and item? I access the
item via an iterator.
As already mentioned, threads are outside of standard so not guarantees
here.
Not for long.
Note first that here the locking problems appear on two
levels: map and item. For map you definitely have to have some
locking.
That is an interesting question, of course. Are the items part
of the map, or not?
If you obtained the item iterator while the map was locked,
then there are good chances that you can dereference the
iterator later and get to the item without locking.
Almost certainly not. Dereferencing the iterator accesses the
map.
If you are obtaining the iterator in a multithreaded regime,
then you have to lock the whole map. Just imagine what happens
if one thread is searching for an item in the map search tree
and the other thread comes along and inserts a new node,
modifying the tree beneath your feet!
Practically speaking, you have to acquire a lock on the map
before getting the iterator, and hold it until you finish using
the iterator.
The dereferencing of iterators in different threads is still
suspect. A paranoid debugging implementation of <map> might
check during this operation that the corresponding map is
alive and the iterator is valid inside there.
And if it doesn't check, using the iterator when this is not
true is undefined behavior.
To be on safer side, you can convert the iterator into a plain
item pointer before releasing the map lock. This breaks any
connection to the map, you have a plain pointer and your
application logic is now responsible for that the pointer
remains valid while used.
Do you have a guarantee of this somewhere? It's obviously not
true if the other thread erases the element from the map, but
I'm not really sure that it's true if if the other thread does
anything which modifies the map. Element level locks are only
valid if you can guarantee no insertions and no deletes in the
map while you hold them. (The usual case where they are used in
in a map which is rarely updated. Client code acquires a rwlock
for read on the map before getting and locking the element.)
Of course, as the map is global, different threads can obtain
a pointer to the same item. If they always do only read-only
access (physically), then there is no problem and no need for
locks. However, because one of the threads finally modifies
the item (when destroying it), the things are not so simple.
If your application logic cannot guarantee that the items are
only referenced by a single thread when deleted, then you
should hold the whole map lock always when working with any
item in the map. For read-only access the items can be copied
out of the map, to release the lock faster.
One way to achieve the above guarantee (single-thread
visibility by destruction) is to use reference-counted
smartpointers to the items in the map (these have to be
threadsafe smartpointers, with locked refcounter
increment/decrement). This ensures that the object can be read
and destroyed safely (but not modified at the same time, for
that you would need other mutexes/locks).
I would very definitely avoid reference counted smart pointers
anywhere the objects could be accessed from multiple threads.
Reference counting means that other threads may end up modifying
a shared object "behind the scenes", without the client code
really being aware of it.
--
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