[LC++]Threading and shared STL containers.

[Carlo Wood]

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.

You have:

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?

> 
> --George
> 
> P.S.  I assume you've read these:
> 
> http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/howto.html#3
> http://www.sgi.com/tech/stl/thread_safety.html
> http://gcc.gnu.org/onlinedocs/libstdc++/23_containers/howto.html   (scroll
> down)

Yes, thanks :).

-- 
Carlo Wood <carlo at alinoe.com>