[Openmcl-devel] slow read-char

[Gary Byers]

I'm in the middle of something totally un-OpenMCL related, but I want
to try to look at this further soon.

The locking involves a few function calls, an interlocked memory
access, and an UNWIND-PROTECT (which itself is a few dozen instructions
and some fussing around with the unlock operation); this is typically
surrounding "get a character out of a buffer and update some counters
and pointers"; if you figure that (probably, most of the time) streams
other than the standard ones are only accessed from a single thread,
that's a lot of wasted overhead.

The simplest way of avoiding it that comes to mind is to introduce
thread-private streams.  I suspect (and this may vary a bit from
person to person) that most application-level streams are only
accessed from a single thread, and it might therefore be appropriate
to make "thread-private" streams be the default.

(The idea would be that rather than locking/unlocking to avoid
shared access, the stream code could just check that the curent
thread is the permanent "owner" of the stream.)

It's also worth checking to ensure that the locking is really
where the problem is.  That seems likely, but it'd probably
be a good idea to run your test case through CHUD/Shark.

On Fri, 14 Jul 2006, Takehiko Abe wrote:

> Gary Byers wrote:
>
>> READ-CHAR has the same per-transaction locking that WRITE-CHAR has,
>> for much the same reasons (reading a character out of the buffer
>> updates a couple of pointers/counters for example, and it'd be bad -
>> though unlikely - for two threads to access/update a stream's state
>> at the same time.
>
> Aha. Thanks. Threads are tough! Maybe I could somehow hold
> the lock around a loop. I'll study further.
>
> regards,
> T.
>
>
>