Hi, On Wed 26 Mar 2014 16:32, Mark H Weaver <[email protected]> writes:
> Andy Wingo <[email protected]> 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/
