[LC++]Threading and shared STL containers.
carlo at alinoe.com
Fri Sep 7 13:56:04 UTC 2001
On Thu, Sep 06, 2001 at 01:05:57PM -0400, George T. Talbot wrote:
> At my last job we followed the following rules:
> 1) Protect all accesses to a shared container with a reader-writer lock.
> 2) Only those operations that change the structure of the container itself
> (insertion, removal, erase all elements, etc.) get the writer lock,
> everything else gets the reader lock.
To recall, I had:
1 == operations that change the structure of the container itself.
2 == operations that read the structure of the container itself.
3 == operations that write to elements pointed to by iterators.
4 == operations that read elements pointed to by iterators.
and a locking sheme:
1 -> lock 1,2
2 -> lock 1,3(all)
3 -> lock 3(same),4(same)
4 -> lock 3(same)
where 3(all) means all elements and 3(same) means the same
element as the current operation works on.
1 -> lock 1,2,3(all),4(all)
2 -> lock 1,3(all)
3 -> lock 1,3(all)
4 -> lock 1,3(all)
You miss a lock on 4(same) for operation 3 thus...
That means your solution is not thread safe as one
thread could be changing an element while another thread
is reading it!
> 3) When the writer locks the container, all live iterators referencing that
> container should be considered invalid when the writer releases the lock.
> Think about number three for a second. It is possible to imagine a list
> implementation that would leave a live iterator dangling after an insertion
> or removal. A possible solution to this is that a const_iterator acquires
> the reader lock at creation, and releases it at destruction.
I don't understand this, when inserting a new element in a container
doesn't invalidate the live iterators - then why would that happen
with multi threading?
> P.S. I assume you've read these:
> http://gcc.gnu.org/onlinedocs/libstdc++/23_containers/howto.html (scroll
Yes, thanks :).
Carlo Wood <carlo at alinoe.com>
More information about the tuxCPProgramming