Thread Synchronisation - Linux

This is a discussion on Thread Synchronisation - Linux ; I'm working on a RedHat Enterprise Linux WS 2.6 application. I intend to use semaphores or mutex for controlling access to shared memory when events like packet arrivals and timeouts occur. However, I understand based on the man pages that ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Thread Synchronisation

  1. Thread Synchronisation

    I'm working on a RedHat Enterprise Linux WS 2.6 application.
    I intend to use semaphores or mutex for controlling access to shared memory
    when events like packet arrivals and timeouts occur.

    However, I understand based on the man pages that a number of the calls for
    semaphores and mutex may cause a deadlock when the calling thread happens to
    be handling an asynchronous signal.

    First of all, what are asynchronous signals in this context? If they refer
    to events whose time occurance is unpredictable, wouldn't such signals apply
    to a really large number of cases, including packet arrivals?

    The man pages say that sem_post is the only POSIX call that handles
    asynchronous signals fine. What use is this if I can't use sem_wait with
    asynchronous signals?

    What is your experience with semaphores and mutex?

    Thanks.



  2. Re: Thread Synchronisation

    Jeremy wrote:
    > I'm working on a RedHat Enterprise Linux WS 2.6 application.
    > I intend to use semaphores or mutex for controlling access to shared memory
    > when events like packet arrivals and timeouts occur.
    >
    > However, I understand based on the man pages that a number of the calls for
    > semaphores and mutex may cause a deadlock when the calling thread happens to
    > be handling an asynchronous signal.
    >
    > First of all, what are asynchronous signals in this context? If they refer
    > to events whose time occurance is unpredictable, wouldn't such signals apply
    > to a really large number of cases, including packet arrivals?


    They mean unix signals, as sent by the kill(1) program, the raise(2)
    call, the kernel etc. man sigaction/man signal.

    Semaphores and mutexes should work fine with such signals, but what
    doesn't work is to operate on these from within a signal handler.
    In a signal handler you can't call malloc/printf/etc., or any of the
    pthread mutex, semaphore etc. function.

  3. Re: Thread Synchronisation

    "Jeremy" writes:

    > I'm working on a RedHat Enterprise Linux WS 2.6 application. I
    > intend to use semaphores or mutex for controlling access to shared
    > memory when events like packet arrivals and timeouts occur.
    >
    > However, I understand based on the man pages that a number of the
    > calls for semaphores and mutex may cause a deadlock when the calling
    > thread happens to be handling an asynchronous signal.
    >
    > First of all, what are asynchronous signals in this context? If they
    > refer to events whose time occurance is unpredictable, wouldn't such
    > signals apply to a really large number of cases, including packet
    > arrivals?
    >
    > The man pages say that sem_post is the only POSIX call that handles
    > asynchronous signals fine. What use is this if I can't use sem_wait
    > with asynchronous signals?


    sem_post() is the only function in this family that is safe to call
    from a signal handler. All the others are safe to use from normal
    threads, even if asynchronous signals are being used. They just can't
    be used in a signal handler. Typical use is to use sem_post() in a
    signal handler wake up some thread blocked in a sem_wait() call, then
    do the main work in that thread.

    --
    Måns Rullgård
    mru@inprovide.com

+ Reply to Thread