[C] lock/unlock mutex POSIX linux

[MrX87]

Ciao a tutti ragazzi...ho una domanda relativamente semplice.....programmando su linux...sto usando le librerie pthread.h che forniscono delle funzioni per la gestione dei mutex(semafori binari).

La domanda è: un mutex può essere gestito da più threads?
Ovvero se faccio la lock() nel thread1 posso fare la unlock dello stesso mutex nel thread2???

Da quello che so di teoria non si potrebbe fare....perchè un mutex se bloccato dal thread1 deve essere sbloccato dal thread1 stesso!!! però volevo trovare su internet un manuale o qualcosa di ufficiale che spiega questo...perchè devo scriverlo in una relazione e devo dare un riferimento ufficiale.

Grazie mille

[Ikitt]

Per potere (nel senso che nessuno te lo impedisce) puoi farlo, ma non riesco a pensare a neppure un caso in cui possa avere senso farlo.

[TuxDroid1]

Qualunque libro/manuale spiega questa cosa, ed è molto intuitivo direi: T1 blocca il semaforo e continua la sua esecuzione. T2 arriva a richiedere il mutex, lo trova occupato, si sospende. Come potrebbe riattivarlo se è sospeso? Direi che l'unico modo per farlo è andare ad azzerare l'utilità della mutua esclusione (T2 richiede l'accesso alla sezione critica, sblocca il mutex se bloccato e accede... tanto vale non metterlo, n'est pas??), quindi nessuna applicazione ben progettata può implementare tale caso!

In ogni caso ti posso dare uno schema generico di funzionamento di lock e unlock, se è questo quello che cerchi...

Prendiamo in esame l'istruzione test and set lock, questa è un'operazione atomica che garantisce a thread che lavorano in parallelo su più processori di non interferire tra di loro nel "bloccaggio" del semaforo. In pseudo-linguaggio macchina puoi immaginarla in questo modo:

Codice: Seleziona tutto

lock(x): 
TSL reg, x     //copia x nel registro e la pone = 1 
CMP reg, 0   //ci chiediamo se il valore era 0 o meno 
JNE lock      //Se non lo era, continuiamo il ciclo
RET                //Ritorna al chiamante e accesso alla sezione critica 

Codice: Seleziona tutto

unlock(x): 
MOVE x, 0  //Inserisce 0 in x
RET            //ritorna al chiamante 

In linguaggio più naturale: TSL copia il valore di x nel registro e cambia il valore di x in uno diverso da zero. La CPU che esegue TSL blocca il bus di memoria per impedire ad altre CPU di accedere alla memoria finchè TSL non termina. Ovviamente qui siamo in presenza di attesa attiva, quindi un thread non si sospende realmente se trova il mutex bloccato, ma continua ad eseguire lock finchè non viene liberato dal thread che ha avuto accesso alla sezione critica.... e chi può essere questo thread, se non proprio l'unico che ha bloccato il mutex???

[MrX87]

Grazie ragazzi per la risposta veloce e concreta....io sono d'accordo con voi che non ha senso....ma mi era stato detto di provare ad implementare lo schema produttore consumatore con una regione critica con soli mutex!!! io da quello che conosco nel metodo classico in questo caso si usano 2 semafori e un mutex solo per l'accesso alla regione critica!!

[TuxDroid1]

Il produttore consumatore è facilmente implementabile con soli mutex:

Produttore:

Codice: Seleziona tutto

lock(); 
consuma(); 
unlock(); 

Consumatore:

Codice: Seleziona tutto

lock(); 
produci(); 
unlock(); 

Ricorda che per quanto detto prima il consumatore sarà in attesa attiva sulla lock, quindi non hai bisogno di ulteriori segnali, condition o semafori per garantire la correttezza del codice. Di certo non è la soluzione migliore, ma è una soluzione!

[MrX87]

Il produttore consumatore è facilmente implementabile con soli mutex:

Produttore:

Codice: Seleziona tutto

lock(); 
consuma(); 
unlock(); 

Consumatore:

Codice: Seleziona tutto

lock(); 
produci(); 
unlock(); 

Ricorda che per quanto detto prima il consumatore sarà in attesa attiva sulla lock, quindi non hai bisogno di ulteriori segnali, condition o semafori per garantire la correttezza del codice. Di certo non è la soluzione migliore, ma è una soluzione!

Si ok...ma come soluzione mi pare abbastanza discutibile per efficienza...nel senso che così se consideri 2 threads separati, 1 per consumatore e 1 per produttore, non avrai il parallelismo delle operazioni giusto??

[TuxDroid1]

Come puoi avere parallelismo se hai necessità di far operare in maniera concorrente i due thread? Se devono accedere alla medesima risorsa è ovvio che si "devono aspettare" . Non possono coesistere operazioni di lettura e scrittura sullo stesso buffer in maniera contemporanea, quindi puoi avere parallelismo fintanto che non devono accedere al buffer, poi è chiaro che uno dei due dovrà sospendersi. Non è possibile realizzarlo diversamente.

Quando parlavo di poca efficienza mi riferivo al fatto che i due thread tengono occupato il processore anche quando sono sospesi!

[MrX87]

ah okok.....bhè no io intendevo comunque che per esempio il thread del consumatore potrebbe avere necessità di elaborare i dati prelevati dal buffer condiviso, quindi potrebbe essere una situazione tipo :

Codice: Seleziona tutto

lock()
consume()
processing()
unlock()
 

dove l'operazione di processing potrebbe impiegare un certo tempo ad elaborare i dati....effettivamente però non avevo pensato che banalmente si può effetteuare il processamento dei dati dopo la unlock.....grazie mille comunque....ottime spiegazioni......se mi viene qualche altro dubbio chiedo....