Subject: Re: pthreads plan
To: Greg Hudson <ghudson@MIT.EDU>
From: Michael Graff <explorer@flame.org>
List: tech-userlevel
Date: 11/06/1999 08:25:01
Greg Hudson <ghudson@MIT.EDU> writes:

> I think the major sticking point is getc() and putc(), which need to
> be (a) fast in normal programs, and (b) MT-safe in pthreads programs.
> You can get the overhead for normal programs down to a single
> condition check by introducing a global flag which gets set when the
> first thread is created.

What about something like this?

_getc():  no multithreaded support
_getc_MT():  locking

and in the header file:
#if defined(_REENTRANT)
	rename(getc, _getc_MT);
#else
	rename(getc, _getc);
#endif

The purpose is to make getc() do locking only when needed.  BTW, if
the mutex locking code can be made at least partially inline, and only
call a function in the failure case, I think life would be much better
for speed, and perhaps the locking overhead could just be ignored.

> Incidentally, MIT pthreads took the approach of making many
> non-reentrant libc functions use thread-specific data; e.g. getpwnam()
> would return its result in a thread-specific buffer so that multiple
> threads can use it.  That's not required by POSIX, so it can be
> punted if it makes life easier.

It would be punted initially at least.

--Michael