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

[Mark H Weaver <mhw@netris.org>]

Andy Wingo <wingo@pobox.com> writes:

> On Wed 26 Mar 2014 06:10, Mark H Weaver <mhw@netris.org> writes:
>
>> Andy Wingo <wingo@pobox.com> writes:
> n>
>>> On Tue 25 Mar 2014 12:14, "Diogo F. S. Ramos" <dfsr@riseup.net> writes:
>>>
>>>> It's not obvious that ports are not thread-safe and trying to have
>>>> multiple threads writing to one returns errors that are not
>>>> recognizable as been caused by this lack of thread-safeness.
>>>
>>> This is a bug, and it is fixed in master.  FWIW.
>>
>> FWIW, I disagree that this is a bug.  I continue to believe that it
>> would be a very serious mistake to promise to do thread synchronization
>> within Guile's standard I/O procedures.
>
> It seems to work for glibc streams.  Why do you think that thread
> synchronization is inappropriate for Guile if it works for glibc?

glibc implements the POSIX API, which (1) mandates that the I/O
functions do thread synchronization, and (2) provides standard
alternatives that avoid thread synchronization.

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.

>> 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.

Here's my test program:

--8<---------------cut here---------------start------------->8---
#include <stdio.h>

int
main (int argc, char *argv[])
{
  int i = 100000000;
  char ch = 'a';

  while (i--)
    {
      putchar (ch);
      if (ch == 'z')
        ch = 'a';
      else
        ch++;
    }
}
--8<---------------cut here---------------end--------------->8---

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.

> and we can disable mutexen entirely for certain ports.

What set of ports would you suggest?  What about when portable programs
do I/O on stdin and stdout?

Since you ignored my strongest point, I'll repeat it:

  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.

     Regards,
       Mark