Re: _IO_MTSAFE_IO

[Szabolcs Nagy <szabolcs dot nagy at arm dot com>]

On 02/05/16 09:32, Florian Weimer wrote:
> On 04/29/2016 04:36 PM, Joseph Myers wrote:
>> On Fri, 29 Apr 2016, Florian Weimer wrote:
>>
>>> Whether applications can use these macros is somewhat debatable, but as I
>>> said, it happens within glibc as well.  There are repeated occurrences of this
>>
>> My view would be:
>>
>> * libio is not a public API for applications; only stdio is (and internals
>> should be avoided in public headers where possible).  But ABI
>> compatibility with old applications using libio may still be needed.
> 
> Yes, we need the ABI compatibility.  I believe some of the stdio macros need <libio.h> or something like it, too.
> 
>> * _IO_* symbols may be used internally in glibc for namespace reasons
>> (where they are function aliases), or if there is another reason for using
>> internals of another part of glibc.
> 
> Makes sense.
> 
>>> Curiously, _IO_flockfile and _IO_funlockfile are only defined in
>>> libpthread.so, not in libc.so.  But these implementations are slightly
>>
>> They seem to be in the libc.abilist files to me....
> 
> Yes, I remembered incorrectly, I got a localplt failure during building.  So there currently aren't any
> _IO_flockfile references in libc.so, they are either expanded inline or they are elided.
> 
> I thought about the _IO_flockfile discrepancy some more.  I believe we should do the following:
> 
> (1) Replace _IO_flockfile references with a new internal function (say __flockfile_nouser).  This new function
> will perform the _IO_USER_LOCK check.
> 
> (2) Remove the symbols currently controlled by _IO_MTSAFE_IO from the API (header file at first, almost of
> _IO_* needs to be made compat-only, as you pointed out, but this is a different issue).
> 

this would be nice to sort out.

i'd propose a related single threaded optimization:
make all stdio apis with _unlocked variant do a check on
the FILE* that tells if the process is multithreaded or
the stream was ever locked, if not then just tailcall the
_unlocked code.

this approach would be more efficient for _IO_USER_LOCK
too which currently does redundant operations.

when the first thread is created, the FILE* with the
optimization have to be updated (and future FILE*
should be created with different initializer), but
this should be possible to do.

the current stdio locking code is slow for single thread
case which is a common usecase (i can measure >10x diff
between getc and getc_unlocked on a machine with admittedly
slow atomics), and i don't think the check would add too
much overhead for the threaded case (e.g. the lock owner
field may be used which is checked anyway).

(x86 seems to have a single thread optimization in libc.so
for lowlevelocks, that is suboptimal and seems to be broken
for pshared locks, it only works because there are no such
locks currently in libc.so, i think higher level target
independent optimization would be better for stdio. malloc
may be a different story, other apis using lll are probably
not performance critical in a single threaded context)