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

    > From: Richard Watts <>
    > 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

    [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

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


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


     \ /
      Last update: 2005-03-22 13:38    [W:0.018 / U:16.196 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site