|
From: Bart V. A. <bar...@gm...> - 2006-08-27 15:10:21
|
Hello Julian,
I did not analyze the libio locking code in glibc in detail. But I think
the purpose of the _IO_lock_lock() macro and friends is that it is a speed
optimization compared to pthread_mutex_lock() and friends: _IO_lock_lock()
only performs a function call when it has to block. If the lock is free, it
proceeds without having to do any function call. There might be a problem
however with _IO_lock_lock() and _IO_lock_unlock(): these macro's assume
that C's increment and decrement operators are atomic. I'm not sure that
this is guaranteed on multiprocessors.
On 8/27/06, Julian Seward <js...@ac...> wrote:
>
> On Sunday 27 August 2006 15:25, Bart Van Assche wrote:
> > Hello Julian,
> >
> > You asked me to look at the drd output for pth_once. Can you please
> be
> > more specific ?
>
> What I originally meant was, can you look at why drd asserted. But since
> that's solved now, investigating the errors from glibc is also useful.
>
> > By this time I looked up why drd complains about
> > _IO_stdfile_1_lock. The reason is simple: at least in glibc
> > 2.3.5_IO_lock_t::cnt and _IO_lock_t::owner are accessed in a
> > non-threadsafe way
> > (_IO_lock_t is a member of _IO_FILE_plus, the datatype of
> > stdin/stdout/stderr). [...]
>
> That's very interesting. Is it a glibc bug or did the glibc authors
> intend that, do you know?
>
|