Thread: pthread_cond_wait() VS. sem_wait()

  1. #1
    Alessio Stella
    Join Date
    May 2008
    Location
    Italy, Bologna
    Posts
    251

    pthread_cond_wait() VS. sem_wait()

    What are advantages/disadvantages of using

    sem_wait() and sem_post() instead of
    pthread_cond_wait() and pthread_cond_broadcast()

    for sincronizing pthreads?

    I guess but please correct me:

    Advantages:
    (1) sem_wait()/post() are more flexible and do not need to be surrounded by mutex lock/unlock
    (2) as a consequence sem_wait() can be used inside signal handlers or async call backs (pthread_cond need pthread_mutex which is not signal handler safe)

    Disadvantages:
    (1) sem_wait()/post are slower? How much slower?

  2. #2
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by mynickmynick View Post
    Advantages:
    (1) sem_wait()/post() are more flexible and do not need to be surrounded by mutex lock/unlock
    A semaphore is like a combination of a mutex and a condition variable. This can't possibly be more flexible than a method where the two are separate.

    (2) as a consequence sem_wait() can be used inside signal handlers or async call backs (pthread_cond need pthread_mutex which is not signal handler safe)
    If you're trying to do any of the above inside a signal handler, then you've missed the point of threading. The async-signal-safety of pthreads is irrelevant. If you wish you could call pthreads calls in a signal handler, this indicates your design is wrong.

    (1) sem_wait()/post are slower? How much slower?
    That would depend on the platform.

    But that's the only disadvantage to semaphores you can come up with? How about:

    1. They necessarily involve a kernel context switch, since they support cross-process operations.
    2. They are a shared resource, which leads to the possibility of a global resource leak.
    3. They are freaking hard to use and understand

    For starters...

  3. #3
    Alessio Stella
    Join Date
    May 2008
    Location
    Italy, Bologna
    Posts
    251
    I need to use something like that on a sort of embedded Vision System where
    in a grabbing thread a Call Back is called (asyncronously as a signal handler) everytime a new frame(picture) is grabbed.
    I need the grabbing thread to tell the processing thread a new frame is ready.
    I cannot do this with a mutexlock flag mutexunlock cause I cannot block inside a call back.
    Either I use sem_post()
    Or May be I could just set a sig_atomic_t variable inside the call back which is then tested inside the grabbing thread, which would then communicate this to the processing thread by mutex_lock flagorwhatever mutex_unlock but I do not know

  4. #4
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by mynickmynick View Post
    in a grabbing thread a Call Back is called (asyncronously as a signal handler) everytime a new frame(picture) is grabbed.
    Why are you using a signal handler? What signal are you catching?

  5. #5
    Alessio Stella
    Join Date
    May 2008
    Location
    Italy, Bologna
    Posts
    251
    So when are sem_wait() sem_post() better than pthread_cond_wait() and pthread_cond_broadcast()??

    I would tend to say rarely?

  6. #6
    Alessio Stella
    Join Date
    May 2008
    Location
    Italy, Bologna
    Posts
    251
    I do not know if it's a signal or an interrupt or whatever.
    It is something internal to the API given by the camera producer.
    At start up you call CaptureQueue(Frame[0] , CallBack ) ... CaptureQueue(Frame[10] , CallBack )

    then do other stuff setup and startup the camera

    when the first picture is grabbed and ready pointed by Frame[0] (all the work is done by the API) the API runs the user-defined function CallBack() which should do very few things and not block (because if a second frame is ready while the first callback is still blocked the result is not sure and reliable (I did not received convincing info about it))
    It is not even clear if this call back is a different thread. The producer says it is an internal thread of the API. But not visible as a separate pthread cause I tested it with pthread_self().

    Anyway my main question is : when sem_wait() is better than pthread_cond_wait() ??
    Last edited by mynickmynick; 05-07-2008 at 09:36 AM.

  7. #7
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,981
    >> when sem_wait() is better than pthread_cond_wait()
    Again, this is really going to depend on your system's implementation of each. If the mutex associated with the condition does not support access by multiple processes - then it *may* be faster.

    You best bet is to use conditions. Get it working then optimize if need be.

    gg

  8. #8
    Alessio Stella
    Join Date
    May 2008
    Location
    Italy, Bologna
    Posts
    251
    i am using linux kernel 2.6.18 Debian distribution (probably gonna use 2.6.23)

  9. #9
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by mynickmynick View Post
    I do not know if it's a signal or an interrupt or whatever.
    It is something internal to the API given by the camera producer.
    At start up you call CaptureQueue(Frame[0] , CallBack ) ... CaptureQueue(Frame[10] , CallBack )
    Whether the callback is invoked within a signal handler is not an implementation detail, it is critical for the library user to know whether this is the case. It will say somewhere in the documentation if the callback must be able to execute in a signal handler context. If not, then it is essentially stating by omission that the context is NOT a signal context.

    Specifying that a user callback must run inside a signal context is plain dumb design -- I can't believe any decent library would do that.

Popular pages Recent additions subscribe to a feed