+---------- On May 23, Todd Volkert said:
> nsv_set global cond [ns_cond create]
> nsv_set global mutex [ns_mutex create]
>
> proc foo {} {
> set cond [nsv_get global cond]
> set lock [nsv_get global mutex]
> ns_cond wait $cond $lock
> }
>
> proc bar {} {
> ns_cond boadcast [nsv_get global cond]
> }
You have to lock $lock before calling ns_cond. ns_cond atomically
unlocks $lock and begins waiting for $cond to be signalled. When $cond
is signalled, ns_cond will reacquire $lock before returning. Note that
only one thread can own $lock at a time, so if you have multiple threads
waiting on the same $cond and $lock, they'll have to take turns owning
$lock.
You also almost always need to lock $lock before calling ns_cond
broadcast and unlock it afterwards to avoid race conditions.
> You run foo as many times as you want in different threads of AOLServer,
> then you run bar from another thread, and only one of the other threads
> wakes up. All other threads are stuck until you bounce your virtual server.
Sounds like one thread (the live one) gets $lock and never releases it.
So the hung threads are all hung in ns_cond waiting for $lock.
