pthread_mutex_init v. sem_init v. sem

Sponsored Content

Top Forums Programming pthread_mutex_init v. sem_init v. sem_get Post 302076643 by siegfried on Wednesday 14th of June 2006 08:24:38 PM

06-14-2006

Registered User

semaphore.h v. sys/sem.h

semaphore.h defines sem_init and sys/sem.h defines semget.

Both functions seem to work on windows/cygwin and SuSE. I'm studying the sample code from the Wrox Press book "Beginning Linux Programming" 3rdEdition which gives examples that work on both SuSE and windows/cygwin. See http://www.wrox.com/WileyCDA/WroxTit...764544977.html .

Apparently, sem_init does not work across process boundaries for linux (according to my SuSE manpage) and sem_get does (for linux).

sem_init seems to be documented at http://www.opengroup.org/pubs/online.../sem_init.html.

semget seems to be documented at http://www.opengroup.org/pubs/online...sh/semget.html

Why are their two APIs for semaphores, especially when they both work across process boundaries (for nonlinux implementations).

Can someone please explain to me what the last argument (named "value") for sem_init is for? Is this the same in concept as the second argument (named nsems) in semget?

In native windows land (not cygwin) I can lock a resource with a semaphore just like I can with a unix or windows mutex. In native windows land a mutex is just a binary semaphore meaning that only a single thread can have access to the resource at one time. In Windows land, one uses a semaphore instead of a mutex when a maximum of "n" threads may acess a single resource simultaneously (as might be used for throttling access to a network resource). Is this true of sem_init and semget for linux and cygwin/windows?

Sometimes, however, I don't want to lock a resource. For example, let's suppose I want to reinvent apache httpd with synchronous sockets and a thread pool implemented with an array of pthread_t. Every thread is initialized with a threadproc and all the threads (initially) sit around blocked waiting for a green light. Now the main thread (not part of the thread pool) blocks on the listen and accept functions. When a remote socket client connects (such as a web browser), the server's main thread returns from the accept function and gives a green light to one of the threads sitting around idle in the thread pool.

How would I implement the green light? In windows I would use an "event" object (which is like a mutex that automatically unlocks it self immediately after being locked) and not a semaphore or a mutex. What should I use in linux?

thanks,
Siegfried

siegfried

View Public Profile for siegfried

Find all posts by siegfried

We Also Found This Discussion For You

1. Programming

Undefined: sem_init, sem_post, sem_wait

Hi friends, I am using semaphores in my program, but when I compile the program, it gives the following error $ gcc sem.c -o sem -lpthread Undefined first referenced symbol in file sem_init ...

LEARN ABOUT OSF1

sem_destroy

sem_destroy(3)						     Library Functions Manual						    sem_destroy(3)

NAME

       sem_destroy - Destroys an unnamed semaphore (P1003.1b)

LIBRARY

       Realtime Library (librt.so, librt.a)

SYNOPSIS

       #include <semaphore.h>

       int sem_destroy (
       sem_t *sem);

PARAMETERS

       sem     References  the	unnamed semaphore to be destroyed.  Use the sem argument that was supplied to, and filled in by, the previous call
	       to sem_init.

DESCRIPTION

       The sem_destroy function destroys an unnamed semaphore indicated by sem.  Only a semaphore created using sem_init may  be  destroyed  using
       sem_destroy.

       The  potential  for deadlock exists if a process calls sem_destroy for a semaphore while there is a pending sem_wait, because a process may
       be waiting for a poster that has not yet opened the semaphore.

RETURN VALUES

       On successful completion, the function returns the value 0 (zero); otherwise, the function returns the value -1 and sets errno to  indicate
       the error, without destroying the semaphore indicated by the sem argument.

ERRORS

       The sem_destroy function fails under the following condition:

       [EINVAL]       The sem argument is not a valid semaphore.

RELATED INFORMATION

       Functions: sem_init(3), sem_open(3)

       Guide to Realtime Programming delim off

																    sem_destroy(3)

We Also Found This Discussion For You

1. Programming

Undefined: sem_init, sem_post, sem_wait

Discussion started by: gabam

LEARN ABOUT OSF1

sem_destroy