> From: Richard Watts <Richard.Watts@cl.cam.ac.uk>
> Date: Tue, 28 Jan 1997 17:24:52 +0000
>
> This is a request for comments on the use of kernel synchronisation
> support. As part of an attempt to implement native threads for Linux
> in SRC Modula-3, I ran into a couple of problems with the user-level
> support provided by things like pthreads :
>
> (i) There seems to be no (adequate) suspend() mechanism.
> (ii) They use up signals, and play around with signal masks, which
> may not be what you want.
>
>What's wrong with sem_wait() and sem_trywait(), which are the standard
>System V mechanisms for handling synchronization?
Nothing at all (except that I'd have to use SIGUSR? for alerts[1]) -
my main problems were suspend() and resume(), but once I'd built the
access control mechanism for those[3], it seemed sensible to put mutices
and conditions in the module rather than fiddling about in user space
afterwards.
[1] Which is a problem in itself, of course, but not many people want
alerts these days - even most Modula-3 programmers don't use them,
though this is a circular argument, since the reason most people
don't use them is because the library implementation doesn't handle
them properly...
[3] Which is, I admit, more complex than necessary - I was aiming
for something more general than `if you share memory, you can
suspend'.
>
>Also, if you want really fast sychronization across native threads (and
>security isn't an issue because all of the accesses are via cooperating
>threads which are at the same security level), you'll want to do this
>via shared memory and some atomic test-and-set instructions. For some
>applications the kernel context switch time will be unacceptable.
Agreed.
>
>See Gallmeister's "Programming for the Real World" book, which documents
>the POSIX.4 (aka POSIX.1b) international standard for doing POSIX
>real-time programming (including semaphores) for more information.
Thanks :-).
Richard.