This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]