lkml.org 
[lkml]   [1997]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Kernel synchronisation support - comments ?
Date
On Tue 28 January 1997, Theodore Y. Ts'o
<tytso@mit.edu> wrote:

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

\
 
 \ /
  Last update: 2005-03-22 13:38    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site