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

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

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.

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