Re: debug mode performance patch

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 9 November 2010 20:53, François Dumont wrote:
>
> As announced I prefer to use a consistent approach in the debug mode locks,
> I always lock the sequence mutex as soon as I start modifying the lists of
> safe iterators within it. In swap we touch to both sequences' lists at the
> same time so we have to lock both mutexes. However I realized that if you
> have a thread iterating over a sequence while you swap it in an other thread
> it has chances to fail in debug mode because when the thread iterating will
> check for sequence end it might do so at a moment where both safe iterators
> has not been assigned to the same safe sequence resulting in an invalid
> comparison of iterators from different sequences. Now the question is
> whether this kind of concurrent usage should be considered as valid ?

It's generally not valid for users to access distinct sequences
concurrently, but your change means that distinct objects share
mutexes behind the scenes, even if users don't share sequences.

There are two problems with _M_swap in your patch:

1) if two objects are swapped whih share the same mutex then it will
try to lock the same mutex twice.  You should be able to reproduce
this like so (untested):

__gnu_debug::vector<int> v[17];
swap(v[0], v[16]);

If I'm not mistaken, v[0] and v[16] should get the same mutex from
get_mutex and so should lock it twice. That's bad, even in a
single-threaded program.

2) consider four sequences, A, B, C and D. They happen to have
addresses such that:

&A.get_mutex() == &C.get_mutex()
and
&B.get_mutex() == &D.get_mutex()

now, in my multithreaded program I do this concurrently:
swap(A, B);   swap(D, C);
I'm not accessing any single object in more than one thread, but it
will deadlock.

The solution is to ensure that you don't lock the same mutex twice and
you always lock in a consistent order