Re: Guile's I/O procedures should *not* do thread synchronization

[Andy Wingo]

Hi,

On Wed 26 Mar 2014 16:32, Mark H Weaver <address@hidden> writes:

> Andy Wingo <address@hidden> writes:
>
>> It seems to work for glibc streams.  Why do you think that thread
>> synchronization is inappropriate for Guile if it works for glibc?
>
> In the Scheme world, things are very different.  The Scheme standards
> provide only one set of I/O primitives, and do not mandate that they do
> thread synchronization.

Do you think they should crash when used from two threads at once?  I
don't think that this acceptable for *any* Guile data structure.

>>> However, if we promise to do thread synchronization, we will condemn
>>> Guile to forever having dog slow 'read-char', 'peek-char', 'write-char',
>>> 'get-u8', 'peek-u8', and 'put-u8' operations.
>>
>> I think you are wrong about "dog slow".  Uncontended mutexes are fast,
>
> I did some benchmarks of 'putchar' vs 'putchar_unlocked' in C, without
> contention.  I think it's fair to assume that the GCC and GLIBC folks
> did a reasonably good job of making both of these as fast as they could.
>
> With gcc -O2, I tested two variants of this program: one with 'putchar'
> and one with 'putchar_unlocked'.  On my YeeLoong (mips64el w/ N32 ABI),
> the 'putchar_unlocked' version is faster by a factor of 26.3.

On my i7-2620M, the difference is only a factor of 3.0.

Now I think I understand your perspective; 26x is terrible.  But surely
this is an architecture problem, and not a Guile problem?  The world
will only get more multithreaded, and ignoring that does no one any
service.

>   Finally, robust programs will have to do their own explicit
>   synchronization anyway.  Multiple threads writing to the same port
>   without explicit synchronization would lead to garbled output that is
>   interleaved at unspecified points.  The situation is even worse on the
>   read side.
>
>   In order to do proper I/O on the same port from multiple threads, the
>   locking _must_ be done within code that understands the meaning of the
>   data being read or written, because only such code can know where the
>   data can be interleaved without producing garbage.

This is a good point but not germane to the crashing issue.

Andy
-- 
http://wingolog.org/