[RFC][BZ #16159] Detecting that recursive mutex recursed.

[Ondřej Bílka]

On Wed, Nov 13, 2013 at 09:54:52PM -0500, Rich Felker wrote:
> On Wed, Nov 13, 2013 at 10:25:23PM +0100, Ondřej Bílka wrote:
> > On Wed, Nov 13, 2013 at 04:14:20PM -0500, Rich Felker wrote:
> > > On Wed, Nov 13, 2013 at 10:02:56PM +0100, Ondřej Bílka wrote:
> > > > On Wed, Nov 13, 2013 at 02:37:46PM -0500, Rich Felker wrote:
> > > > > On Wed, Nov 13, 2013 at 08:03:56PM +0100, Ondřej Bílka wrote:
> > > > > > On Wed, Nov 13, 2013 at 01:12:57PM -0500, Rich Felker wrote:
> > > > > > > On Wed, Nov 13, 2013 at 02:46:08PM +0100, Ondrej Bilka wrote:
> > > > > 
> > > > > > Alternative solution that I wanted to avoid is to use additional
> > > > > > thread-local variable to detect signals. A count would be maintained by
> > > > > > atomic increment/decrement.
> > > > > > 
> > > > > > Do you know how to generate cmpxchgb instruction without lock prefix as
> > > > > > there is no need of interthread synchronization?
> > > > > 
> > > > > Why do you need any atomicity or asm? In principle, read, modify,
> > > > > write is perfectly valid for this usage as long as the write is atomic
> > > > > (e.g. not using 2 16-bit writes to implement a 32-bit write). If
> > > > > you're not happy assumin 32-bit writes are atomic, then yes, a little
> > > > > more work would be required.
> > > > >
> > > > You cannot do that as you are at mercy of compiler. With volatile
> > > > variable gcc will not use read-modify-write. Without that gcc in
> > > > int x = 0;
> > > > int main(){
> > > >    int z=1;
> > > >    x++;
> > > >    if (x<3)
> > > >     z=0;
> > > > 
> > > >    x--;
> > > >  return z;
> > > > }
> > > > happily optimizes x++ and x-- away.
> > > 
> > > You forgot the mutex lock or unlock (full barrier) in between.
> > > 
> > No, we are in part that uses atomics for synchronization.
> 
> In that case, any compiler barrier should work. You could just make x volatile 
It wont, following example gets expanded to this assembly
volatile int x;
int foo(){
  x++;
}

        movl    x(%rip), %eax
        addl    $1, %eax
        movl    %eax, x(%rip)

Now processor issued 
movl    x(%rip), %eax
Then signal is delivered, this calls foo again incrementing x. After
resuming from handler processor issues

        addl    $1, %eax
        movl    %eax, x(%rip)

which causes x have a wrong value.

>or use a memory-clobber asm block.

I need to do this portably. I asked for CAS without lock overhead as it
is most general and in other applications atomic increment do not
suffice.