Re: std::map multithreaded access, lock needed?
On Jan 11, 9:55 am, "Chris Thomasson" <cris...@comcast.net> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in
message news:3b061c3e-bdd0-4a5e-bb3b->
986cbd0eb...@v4g2000hsf.googlegroups.com...
On Jan 10, 4:10 pm, CodeCracker <sanjaym...@gmail.com> wrote:
Yes you will need to put the lock before handling the map.
Since other thread might have created the entry in the map and
would might be deleting it once they are done. Ifit is created
only once and is never deleted during operation then you would
not need the locking mechanism.
That doesn't sound to clear to me. Even if you never delete
anything, you need to synchronize access. The only case where
you wouldn't need to synchronize access is if the map were
completely filled before you started threading (or before it
became visible to other threads); as soon as any thread modifies
anything, all accesses must be synchronized.
Humm... Well, if you use std::map, then you are 100%
correct... However, I feel the need to point out that one can
create their own map structure which does not need to
synchronize reads in the sense that PDR algorithms can be
employed to manage the memory visibility concerns wrt removing
items and deallocating then from the collection. Think RCU...
One can imagine just about any contract one wishes. But the
interface of std::map pretty much makes anything stronger than
the SGI guarantees useless anyway. Anytime you return a means
of access (e.g. reference, pointer or iterator) into the data of
the map, you need to synchronize somehow at a higher level, in
order to prevent the referenced object from disappearing under
your feet, or otherwise being modified without your knowledge.
You need some sort of synchronization for the larger context
anyway.
--
James Kanze (GABI Software) mailto:james.kanze@gmail.com
Conseils en informatique orient=EF=BF=BDe objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=EF=BF=BDmard, 78210 St.-Cyr-l'=EF=BF=BDcole, France, +33 (0)1 30 2=
3 00 34