Re: mutexes and const_iterators
Paavo Helde a =E9crit :
James Kanze <james.kanze@gmail.com> wrote in
news:7e997e8e-3daa-44eb-8744-07fac88a6b2e@u72g2000hsf.googlegroups.com:
(Note: this is becoming very off-topic, the right group would
be comp.programming.threads).
Not necessarily. We are talking about guarantees which are
given by std::map.
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.
[...]
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?
That depends on the application design.
It depends more on the contract that std::map specifies. As it
is currently written in the SGI pages, I think that they are.
On the other hand, as implemented (in the implementations I know
of), the restriction isn't necessary.
[...]
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
23.1.2 [lib.associative.reqmts] says:
The insert members shall not affect the validity of
iterators and references to the container, and the erase
members shall invalidate only iterators and references to
the erased elements.
I am not very strong in standardese, but I understand this so
that a plain pointer to an item is holding such kind of
reference which is guaranteed to remain valid by the standard.
Yes, but the above doesn't say anything about accessing through
the pointer if another thread is modifying the map.
Again, I'm concerned about guarantees. I *think* that with the
usual implementation, there should be no problem (supposing, of
course, that the modifications in the map don't delete the
object your using). The fact that a pointer is valid doesn't
mean that you can access through without synchronization.
If I understand the SGI guarantees correctly: a container
includes all of its elements as part of the container. Thus,
any access to an element in the container, regardless of how, is
invalid if the container is being modified.
Of course, this also means (literally) that using element locks
on a container whose topology isn't modified is also undefined
behavior. Which doesn't seem right, and certainly isn't
necessary. I think it's an aspect that the committee will have
to address. (Threads are already part of the current working
draft.)
Deletion of the item would of course invalidate the pointer,
hence the refcounting trick I talked about.
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
I believe insertions and deletions of unrelated items are OK,
they don't affect the lifetime and memory location of the
locked item; also, no sane map implementation would read or
modify the content of unrelated items (it may read map keys
for comparisons, but not the stored items).
The problem with this is that you are interpolating into the
implementation of the container for the guarantee. I agree that
it does seem reasonable for the containers to offer this
guarantee. I'm not sure that any do, though.
I guess this is not guaranteed by the standard because it does
not contain any multithreading issues, but I would expect this
to hold for all implementations which support multithreading.
I suspect that in practice, it does. But there doesn't seem to
be any guarantee of it that I can find.
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.
The code potentially modifying the shared object is also
client code - the map won't touch your items unless asked. So
nothing happens 'behind the scenes'. And refcounting does not
protect against modifications, it only protects against
unexpected deletion of the object.
What I mean was modification of the reference counter itself.
In the end this is a question of perfomance and (possibly
premature) optimization. In a multithreaded server application
you want to release any global lock ASAP.
But no sooner:-).
This means that once you have found your item in the map, you
have either to perform the operation on the item immediately,
or copy out the needed information, release the lock and
perform the operation later. Which way is appropriate depends
on the application requirements. First way is definitely
simpler and easier to get right. However, if the performance
issues dictate the second approach, then about the absolute
minimum of information which can be copied out is the raw
pointer to the item. Alas, this brings the item ownership,
item-level locking and item destruction problems we are
talking about. So this approach should be taken only if
performance issues absolutely demand it. I should have been
clearer about this in my first post.
What I would hope (but I don't see the official guarantees there
yet) is that:
if no thread is modifying the topology of the container
(i.e. adding or removing elements), some sort of element
level locking could be used, and
if the container is only rarely modified, some sort of
read/write lock on the container, combined with element
level locking could be used.
I'm not quite sure how to formulate this in standardese,
however. Especially as I don't think that the standard will
contain rwlocks, at least in the next version.
--
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