Messages in this thread |  | | From | Richard Watts <> | Subject | Re: Kernel synchronisation support - comments ? | Date | Wed, 29 Jan 1997 10:05:36 +0000 |
| |
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.
|  |