Re: stdio thread safety

[Carl Norum <carl at lytro dot com>]

On Jun 4, 2013, at 1:21 AM, Corinna Vinschen <vinschen@redhat.com> wrote:
> Just override the definitions in sys/lock.h by providing your own
> sys/lock.h, along the lines of:
> 
>  typedef __your_lock_type _LOCK_T;
>  typedef __your_lock_recursive_type _LOCK_T;
> 
>  #define __lock_init(__lock)  __your_lock_init(__lock)
>  #define __lock_init_recursive(__lock) __your_lock_init_recursive(&__lock)
>  #define __lock_close(__lock) __your_lock_fini(&__lock)
>  [...]

That's pretty much what I've come up with.  I had to do some jiggery-pokery in 
the 'acquire' routine, since it appears newlib assumes that locks can be created
at global scope/static storage class, which they can't in my environment.  I
didn't want to change the interfaces, though, so I left that as is for now.

I've attached a patch that creates a new "sys/arm/sys/lock.h" to override the
default lock.h file.  It uses the __SINGLE_THREAD__ definition to decide 
whether or not to include references to the user-defined functions.  Is this
patch something newlib might want to take?   I think it should be pretty 
generic.  Let me know if there are some changes I can make to make it more
palatable.

>> Right now, I've worked around it by using the linker to make wrap
>> functions that lock access to stdio, but that's not very pretty.  I
>> may have to do something like this anyway, though - the new
>> nano-malloc looks good, but it's explicitly not thread safe (the
>> MALLOC_LOCK and MALLOC_UNLOCK functions are defined to be nothing in
>> the source).
> 
> Yes, that has been discussed and the original developer is hopefully
> looking into adding thread safety soon.


It's possible that just fixing those macros will solve the problem.  I 
haven't yet looked too much into the details of the implementation.

-- 
Carl Norum
carl@lytro.com

Attachment: 0001-Add-support-for-multithreading-to-ARM-port.patch
Description: Binary data