Re: Порядок захвата mutex'ов.

From

Lev Walkin ()

To

mitrohin a.s. ()

Date

2003-05-29T17:19:16Z

Area

RU.UNIX.PROG

From: Lev Walkin <vlm@netli.com>


mitrohin a.s. wrote:
> Anton Petrusevich <casus@att-ltd.biz> wrote:
>  AP> mitrohin a.s. wrote:
> 
> 
>>>imho имелось ввиду что поток проснется, но застрянет внутри cond_wait() на
>>>захвате mutex.
> 
> 
>  AP> А я его не захватывал ваще. Смотри:
>  AP> тред1: лок, вэйт, анлок
>  AP> тред2: сигнал
>  AP> синхронизация была сделана другими сигналами/мутексами. Т.е. есть пул
>  AP> тредов, им даются задания, если все треды заняты и задания давать некому,
>  AP> то выполнялась последовательность "тред1", когда кто-то освобождался, он
>  AP> давал сигнал. Так вот, "тред1" просто не просыпался.
> 
> вот и вы на ступили на те же грабли что и я ;)))
> 
> нельзя пользоваться cond без вспомогательной переменной
> 
> 	thread 1			thread 2
> -------------------------------------------------------------------
> 					cond_broadcast()
> 	cond_wait()
> 
> broadcast пришел до того как первый поток сел на cond_wait()
> и естественно этот broadcast не получил ;))
> 
> 
> 
> volatile int signalled = 0;
> 
> thread1()
> {
> 	...
> 
> 	mutex_lock(mtx)	
> 	while (!signalled)
> 		cond_wait(cond, mtx);
> 	mutex_unlock(mtx);
> 
> 	...
> }
> 
> thread2()
> {
> 	...
> 
> 	mutex_lock(mtx);		|	mutex_lock(mtx);
> 	signalled = 1;			|	signalled = 1;
> 	cond_broadcast(cond);		|	
> 	mutex_unlock(mtx);		|	mutex_unlock(mtx)
> 					|	cond_broadcast(cond);
> 
> 	...
> }
> 
> и для thread2() фиолетово где cond_broadcast(), внутри блока lock-unlock
> или нет...

А вот интересно, как thread 2 произведет сигнализирование путем вызова
cond_broadcast(), когда он не может сделать mutex_lock(mtx), потому что
thread 1 сам себе висит на while(), захватив mtx?


-- 
Lev Walkin
vlm@netli.com

--- ifmail v.2.15dev5
 * Origin: Netli, Inc. (2:5020/400)