Question

I’m working on a problem which we have to use semaphores to solve. I have an array which contains two semaphores, gsem, and given certain conditions call sem_wait(&(gsem[me])), which is supposed to waiting until that particular process is woken up. However, for some reason it gives me the error Bad file descriptor. I looked up sem_wait and the Open Group spec says this is not an error sem_wait can cause. This is making my whole program crazy and I have no idea why this is failing.

EDIT: Offending code, as requested.

120     sem_wait(&mutex);
121     if (inside[opp] > 0 || waiting[opp] > 0) {
122         sem_wait(&screen);
123         printf("%s %u waiting\n", names[me], t);
124         sem_post(&screen);
125         waiting[me]++;
126         sem_post(&mutex);
127         int hg = sem_wait(&(gsem[me]));
128         if (hg < 0)
129             printf("%s\n", strerror(errno));
130     } 

I should note this is a homework assignment for which we are required to use semaphores. The professor calls it the “unisex bathroom”. Either men and women can use it, but not simultaneously. inside[opp] is the number of people of the opposite sex in the bathroom. waiting[opp] is the number of the opposite sex waiting to use it. screen is a semaphore which locks access to stdout. The solution is based on a solution to the readers/writers problem given in our textbook which uses passing the baton.

I should also note that we first had to code a solution in Ada and then convert it to C. My Ada solution works, and I translated it verbatim. I’m sure it’s some minor syntactical detail. Lastly, I’m working on Snow Leopard, if that helps.

Answer 1

Keep in mind that the Single UNIX Spec may not necessarily be the controlling document in your case. Granted, it probably should be, but since you haven’t actually specified the platform, it may be that you’re in an environment that decided to follow different rules and/or have other return codes.

A couple of things to check.

1/ Are you sure that sem_wait is returning -1? I’ve seen coders simply check errno following a call, not realising that most calls don’t set it to zero on success, rather they simply leave it alone. It’s possible that such a situation would arise if errno were set to EBADF before the sem_wait call.

2/ Have you followed all the rules in creating the semaphores, such as initialising them?

3/ Are you referring to a valid semaphore? Primarily, are you certain that the me index is not out of range?

Short of seeing some code, that’s about all the advice I have to give.

---

One thing I found with a cursory google of sem_wait ebadf is here. Turns out this was a problem with using errno in a threaded environment without including the correct headers.

By doing that, the global errno value was being used rather than the correct threaded macro (which would give the thread-specific errno).

Whether that’s your problem, I have no idea, but it may be worth looking into.

---

And following that chain of messages a little more closely, there are some other possibilities.

4/ Are you using sem_init to initialise the semaphores. If so, check its return value. The messages are from 2008 so it may be dated information, but OSX may still not support sem_init, preferring sem_open (see here). You really should check the return codes from all your sem_ functions as well, just to be certain (if you’re using sem_init for them all (and if it’s unsupported) and are only checking one, you may find that they’re all failing).

5/ There is (was?) a race condition in the thread errno function chain under OSX where the __error function called another library call pthread_self before using errno (in main thread, or current_thread->errno in other threads). Technically this is not allowed and there was a small window where problems could occur.