2009-08-18 8 views
10

In una classe di laurea, abbiamo dovuto usare i semafori per realizzare il lavoro con i thread.sem_init (...): A cosa serve il parametro pshared?

Siamo stati indirizzati all'utilizzo di sem_init insieme a una serie di altre procedure sem_ *, ma non abbiamo ricevuto molte informazioni sui dettagli di ciascuno di questi metodi sem_ *.

Il prototipo (e file di intestazione) di sem_init è the following:

#include <semaphore.h> 

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

ma non capisco quale sia il valore pshared viene utilizzato per. Secondo opengroup.org:

Se l'argomento pshared ha un non zero valore, allora il semaforo è condivisa tra processi; in questo caso, qualsiasi processo che possono accedere al semaforo sem può utilizzare sem per eseguire sem_wait(), sem_trywait(), sem_post(), e sem_destroy() operazioni.

ma immagino che non capisco la differenza tra diciamo 1,2, 10, 25, 50000, ecc penso che sta dicendo che se il valore è 0, allora il semaforo non è condivisa. (Ma allora, qual è il punto?)

Come utilizzare in modo appropriato questo parametro pshared?

risposta

12

La versione GLIBC di sem_init (quello che si ottiene se si man sem_init su Linux) ha questo da dire:

"L'argomento pshared indica se questo semaforo è di essere condivisa tra i thread di un processo, o tra processi. "

Così pshared è un valore booleano: in pratica valori significativi passati ad esso sono false (0) e true (1), anche se qualsiasi valore diverso da 0 sarà trattato come vero. Se lo passi 0 otterrai un semaforo a cui altri thread possono accedere nello stesso processo, essenzialmente un blocco in-process. Puoi usare questo come mutex, o puoi usarlo più in generale per le proprietà di conteggio delle risorse di un semaforo. Probabilmente se i pthread supportassero un'API di semaforo non avresti bisogno di questa funzione di sem_init, ma i semafori in Unix precedono di pthreads di un bel po 'di tempo.

Sarebbe meglio se il booleano fosse una sorta di elenco (ad esempio SEM_PROCESS_PRIVATE vs SEM_PROCESS_SHARED), perché non avresti avuto questa domanda, ma i semafori POSIX sono un'API abbastanza vecchia come queste cose vanno.

+0

Risposta stupenda, grazie per la spiegazione. –

+0

Sei il benvenuto. Grazie per il complimento :). – quark

+0

Non è il PC a chiamare questa versione come appartenente a GLIBC. È POSIX.1-2001. –

1

Direi che non c'è alcuna differenza significativa tra il valore s 1, 2, 5 e così via rispetto al parametro shared. Probabilmente è scritto in questo modo perché quando l'API è stata creata per la prima volta, C non aveva tipi booleani.

+0

Quindi questo lo rende un'API obsoleto? – Sneakyness

+0

Non so - a volte c'è valore nell'avere l'uso di una vecchia API "provata e testata". Dovresti guardarlo dal punto di vista di cose come l'efficienza e evidenti difetti di sicurezza per dire se fosse davvero obsoleto o no –

+0

Malumore: Sì e no. No in quel Pthreads, la scelta più moderna, non sembra avere un'implementazione di semaforo, quindi per quei casi in cui vuoi i semafori è l'API che avresti bisogno di usare. Sì, nella maggior parte dei casi i mutex e le condizioni andranno bene al posto dei semafori. – quark

1

L'argomento pshared indica se questo semaforo deve essere condiviso tra i thread di un processo o tra processi.

Se pshared ha il valore 0, il semaforo viene condiviso tra i thread di un processo e deve trovarsi in un indirizzo visibile a tutti i thread (ad esempio, una variabile globale o una variabile allocata dinamicamente sul mucchio).

Se pshared è diverso da zero, il semaforo viene condiviso tra i processi e deve trovarsi in un'area di memoria condivisa (vedere shm_open (3), mmap (2) e shmget (2)). (Poiché un figlio creato da fork (2) eredita i mapping della memoria del genitore, può anche accedere al semaforo.) Qualsiasi processo che può accedere all'area di memoria condivisa può operare sul semaforo usando sem_post (3), sem_wait (3), ecc.