2009-08-18 36 views
10

En una clase de posgrado, hemos tenido que usar semáforos para lograr el trabajo con hilos.sem_init (...): ¿Para qué sirve el parámetro pshared?

Nos indicaron que usáramos sem_init junto con un montón de otros procedimientos sem_ * pero no recibimos mucha información sobre los detalles de cada uno de estos métodos sem_ *.

El (y archivo de cabecera) prototipo de sem_init es the following:

#include <semaphore.h> 

int sem_init(sem_t *sem, int pshared, unsigned int value); 

pero no entienden lo que se utiliza el valor de pshared. De acuerdo con opengroup.org:

Si el argumento pshared tiene un cero no valor, a continuación, el semáforo se comparte entre los procesos ; en este caso, cualquier proceso que puede acceder el semáforo sem puede utilizar sem para realizar sem_wait(), sem_trywait(), sem_post(), y sem_destroy() operaciones.

pero supongo que no entiendo la diferencia entre decir 1,2, 10, 25, 50000, etc. Creo que está diciendo que si el valor es 0, entonces el semáforo no se comparte. (Pero entonces, ¿cuál es el punto?)

¿Cómo utilizo adecuadamente este parámetro pshared?

Respuesta

12

La versión GLIBC de sem_init (lo que se obtiene si se man sem_init en Linux) tiene esto que decir:

"El argumento pshared indica si este semáforo es ser compartida entre los hilos de un proceso, o entre procesos ".

Así pshared es un valor booleano: en valores significativos de práctica se le pasan son false (0) y true (1), aunque cualquier valor distinto de 0 será tratado como verdadero. Si lo pasa 0 obtendrá un semáforo al que se puede acceder mediante otros hilos en el mismo proceso, esencialmente un bloqueo en proceso. Puede usar esto como un mutex, o puede usarlo de manera más general para las propiedades de recuento de recursos de un semáforo. Podría decirse que si pthreads soportara una API de semáforo, no necesitaría esta característica de sem_init, pero los semáforos en Unix preceden a los subprocesos bastante tiempo.

Sería mejor si el booleano fuera algún tipo de enumeración (por ejemplo, SEM_PROCESS_PRIVATE vs SEM_PROCESS_SHARED), porque entonces no habría tenido esta pregunta, pero los semáforos POSIX son una API bastante antigua.

+0

Respuesta impresionante, gracias por la explicación. –

+0

Eres bienvenido. Gracias por el cumplido :). – quark

+0

No es PC llamar a esta versión como perteneciente a GLIBC. Es POSIX.1-2001. –

1

Diría que no hay una diferencia significativa entre el valor s 1, 2, 5 y así sucesivamente con respecto al parámetro shared. Probablemente está escrito de esa manera porque cuando se creó la API, C no tenía tipos booleanos.

+0

¿Eso lo convierte en una API obsoleta? – Sneakyness

+0

No sé, a veces también tiene valor tener el uso de una API "probada y probada" más antigua. Tendría que mirarlo desde el punto de vista de cosas como la eficiencia y los obvios defectos de seguridad para decir si realmente estaba desactualizado o no –

+0

Disimulo: Sí y no. No en ese Pthreads, la opción más moderna, no parece tener una implementación de semáforo, por lo que para aquellos casos en los que quieras semáforos esa es la API que deberías usar. Sí, porque en la mayoría de los casos, mutexes y condiciones funcionarán perfectamente en lugar de semáforos. – quark

1

El argumento pshared indica si este semáforo debe compartirse entre los hilos de un proceso o entre procesos.

Si pshared tiene el valor 0, el semáforo se comparte entre los hilos de un proceso y debe ubicarse en alguna dirección visible para todos los hilos (por ejemplo, una variable global o una variable asignada dinámicamente en el montón).

Si pshared no es cero, el semáforo se comparte entre procesos y debe ubicarse en una región de memoria compartida (ver shm_open (3), mmap (2) y shmget (2)). (Como un niño creado por fork (2) hereda las asignaciones de memoria de sus padres, también puede acceder al semáforo). Cualquier proceso que pueda acceder a la región de memoria compartida puede operar en el semáforo usando sem_post (3), sem_wait (3), etc.