lkml.org 
[lkml]   [1996]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Subjectreal POSIX.1b semaphores
    From
    Date

    Hi,

    I thought a bit about real POSIX.1b semaphores. Since the defined
    interface allows global semaphores we clearly need kernel support.

    For the sake of speed we should try to be able to handle as much
    as possible on user level. The both kinds a POSIX semaphore can
    be reduced to one form. I thought about the following but please
    don't take this as a well-thought design. I have not much experience
    with kernel programming.

    - reserve two pages in the mmap area of each process. The first page
    is for global locks, ie.e., the very same page is shared by all
    processes. The second page is shared between all threads of a
    process (i.e., clone needs another flag).

    The pages should be write protected.

    - each semaphore uses sizeof(unsigned int) bytes, normally 4.

    - one possibility to create a semaphore is to call sem_init(). This
    will have to be a syscall. It returns a pointer to an address in
    either of the semaphore spaces, depending on the value of the PSHARED
    argument. The initial value is given by the third parameter.

    - removing the semaphore need not be explained. There must in any case
    be an allocation bitmap or something like this. This function again
    needs a syscall.

    - Creating a semaphore using sem_open() requires to have another resource,
    a pseudo file system where the names are allocated. The standard leaves
    it open whether this names are visible in the normal filesystem but I
    think it is very useful.

    Would it be difficult to extend the proc/ filesystem to dynamically
    create a hierachy of dirs for the semaphores?

    In any case each known name must reference an address in the global
    semaphore page. Using sem_open() with an unknown semaphore and O_CREAT
    will allocate a new semaphore, just like sem_init(). The return value
    of this function is again a pointer and so all the other sem_*()
    functions can handle semaphores created by sem_init() and sem_open()
    in the same way.

    - calling sem_close() will of course decrement the reference count, but
    not from the pseudo-filesystem if it is zero. There is another function
    sem_unlink() which will remove the semaphore.
    This again requires a syscall or two.

    - the function sem_getvalue() is implemented trivially by reading the
    addressed memory location of the semaphore. No kernel action is
    required.

    - the function sem_wait(), sem_trywait(), and sem_post() will write to
    the memory for the semaphore and cause a bus error. Now the action
    can be performed be the kernel.

    I don't know whether it is possible to work with one single memory
    location for the action and decode the instruction or (unlikely).
    Perhaps using two or three word for each semaphores is necessary.
    So it could be decided based on the address chosen. It would be up
    to the library to choose the correct location.


    Would this be reasonable? Does anybody plan to do something like
    this? We really should have this soon now that multi-threading
    only has limits in the kernel. The libpthread and the libc (=glibc)
    are ready.

    If anybody has interest I could provide the informations from
    the standard. Thanks to RedHat I now have the full POSIX.1 standard.


    (PS: A second *very* important task would be to implement CLONE_PID.)

    Thanks,

    -- Uli
    --------------. drepper@cygnus.com ,-. Rubensstrasse 5
    Ulrich Drepper \ ,--------------------' \ 76149 Karlsruhe/Germany
    Cygnus Support `--' drepper@gnu.ai.mit.edu `------------------------

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