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

[Rich Felker <dalias at aerifal dot cx>]

On Thu, Nov 14, 2013 at 12:20:29PM +0100, OndÅej BÃlka wrote:
> 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.

Perhaps I misunderstand your usage case. I am assuming the value you
intend to increment/decrement is a nesting level, in which case the
original value would always be restored before any signal handler
returns. If the signal handler runs before the increment result is
written, the observable effect is then identical to what would happen
if the signal handler ran just before the start of the "x++;"
statement in the abstract machine.

> >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.

__asm__ with empty body is portable to all GCC targets, no?

Rich