Is sem_getvalue() dangerous?

This is a discussion on Is sem_getvalue() dangerous? within the C Programming forums, part of the General Programming Boards category; I seem to recall a teacher saying that sem_getvalue() could be dangerous. Is this true? If so, why? In what ...

  1. #1
    Registered User
    Join Date
    Nov 2006
    Location
    Coimbra, Portugal
    Posts
    64

    Is sem_getvalue() dangerous?

    I seem to recall a teacher saying that sem_getvalue() could be dangerous. Is this true? If so, why? In what circumstances?

    I'm asking you this question because I'm currently doing an assignment where I need to use named semaphores (yes, the POSIX ones). I wanted to have a named semaphore whose behaviour would be equal to that of a mutex - either its value is 0 or 1, but never higher than 1. Here's what I wanted to do (this code is merely representative):

    Code:
    void my_sem_post(my_named_semaphore) {
      sem_wait(can_update_named_semaphore);
      if (sem_getvalue(my_named_semaphore) == 0) {
        sem_post(my_named_semaphore);
      }
      sem_post(can_update_named_semaphore);
    }
    I hope this doesn't sound too awkward...
    Name: Miguel Martins
    Date of birth: 14th August 1987

    "He who hesitates is lost."

  2. #2
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,674
    Well, it's dangerous if misused. It all depends on how you use the returned "value" of the semaphore. What you have to realize is that the returned "value" is only a snapshot of what the value was at the time of the call. So as soon as sem_getvalue() returns a value, it's possible for the semaphores value to change asynchronously.

    So it looks like you are using "can_update_named_semaphore" as a separate mutex for exclusive access to "my_named_semaphore". That way the returned value of sem_getvalue() will be the *real* value up until the "can_update_named_semaphore" mutex is released (assuming that all other access to "my_named_semaphore" is protected by "can_update_name_semaphore").

    >> I wanted to have a named semaphore whose behavior would be equal to that of a mutex - either its value is 0 or 1
    Why not just use a single semaphore with an initial value of 1? Then if all sem_wait()'s are balanced with sem_post()'s, the value should always be 0 or 1.

    gg

  3. #3
    Registered User
    Join Date
    Nov 2006
    Location
    Coimbra, Portugal
    Posts
    64
    Now that I'm answering back, I don't think I'll need a "mutex-like" named semaphore, anymore, but tell me this: how would I solve this problem?

    Code:
    //Process A
    //Waits for messages on a shared memory buffer (at least that's what I'm supposed to do)
    sem_wait(messages);
    (...)
    
    //Process B
    //Notifies process A that there are messages for A in the buffer
    sem_post(messages);
    (...)
    Here's the deal: I wanted process A to act pretty much like a cleaner - when there's messages for it, process them and clean the buffer. But the problem in this situation is that there could be more than one "sem_post" by process B (you don't know, the process scalonator could give Process B the time to do it). If that were the case, process A could do multiple "sem_wait" - the first "sem_wait" would lead process A to clean the buffer, but the second one would be completely useless, since the buffer is already cleaned!

    If the "messages" named semaphore acted like a mutex, process A would only perform the "sem_wait" operation as necessary.

    I hope this isn't too confusing for you.
    Name: Miguel Martins
    Date of birth: 14th August 1987

    "He who hesitates is lost."

  4. #4
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,674
    You could use a zero value initialized semaphore just for keeping track of "number of messages in Q". Then producers for the Q would use sem_post() to increment the sem's value. Consumers of the Q could use sem_trywait() to prevent from blocking if there's currently nothing to consume.

    Keep in mind that this is just a resource counter. You still need to provide proper synchronization to your shared memory buffer.

    gg

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 2
    Last Post: 12-06-2008, 01:17 PM
  2. Is shared_ptr dangerous?
    By Elysia in forum C++ Programming
    Replies: 19
    Last Post: 04-07-2008, 02:02 AM
  3. why is duplicate code dangerous?
    By agentsmith in forum C Programming
    Replies: 14
    Last Post: 01-08-2008, 12:10 AM
  4. Dangerous System Functions for Servers ???
    By Moni in forum C++ Programming
    Replies: 6
    Last Post: 09-30-2003, 10:55 PM
  5. Why is the gets function dangerous?
    By Kevin.j in forum C Programming
    Replies: 2
    Last Post: 09-27-2002, 05:18 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21