Hi Vikas,
First of all, please put proper subject on mail
always.
It is difficult to tell what exactly went wrong
without seeing code, but there is one case in which
deadlock can occur.
1.) Signal the condition variable before any thread is
waiting on it. This is the only problem with this
synchronization method. In this case singal lost and
when Linux reschdeule other threads, it starts waiting
on condition variable and blocked forever. This race
condition will arise only between checking the flag
value and signaling or waiting on the condition
variable.
This case can be easily avoid by following some basic
steps. Please check your flow whether it confirms to
following or not.
Thread waiting for condition variable:
1. The loop in thread_function locks the mutex and
reads the flag value.
2. If the flag is set, it unlocks the mutex and
executes the work function.
3. If the flag is not set, it atomically unlocks the
mutex and waits on the condition variable ( call
pthread_cond_wait() ).
Thread that can modify flag value or can effect
predicate value:
1. Lock the mutex accompanying the condition variable.
2. Take the action that may change the sense of the
condition.
3. Signal or broadcast the condition variable,
depending on the desired behavior. (call
pthread_cond_signal() or pthread_cond_broadcast()
function)
4. Unlock the mutex accompanying the condition
variable.
_flag value can be predicate value._
and in last before destorying the condition variable
always do the following:
while (pthread_cond_destroy(&cond) == EBUSY)
{
pthread_cond_broadcast(&cond);
pthread_yield();
}
Please tell us if it above information is helpful for
you or not.
With Regards,
Arvind Bharti
--- Vikas Gandhi <[EMAIL PROTECTED]> wrote:
> I am facing a peculier problem in threads. This is a
> problem of condition
> variables. My one functions is waiting infinitely to
> get a signal. Even when
> I deliver a signal, it is not caught in the other
> function which is waiting
> for an infinite amount of time to recieve the signal
> and proceed further.
> Further speaking I replaced this by broadcast. I
> have failed in that also.
> So I replaced infinite timed wait with wait for 1
> sec in a conditional while
> loop with a predicate check and this works fine. To
> further my observations
>
> Is there a defect in thread implementations or we
> just should not check
> conditions this with the usage of any predicates. We
> always see the
> following statement for threads in man pages
> When using condition variables there is always a
> Boolean predicate involving
> shared variables associated with each condition wait
> that is true if the
> thread should proceed. Spurious wakeups from the
> pthread_cond_timedwait() or
> pthread_cond_wait() functions may occur. Since the
> return from
> pthread_cond_timedwait() or pthread_cond_wait() does
> not imply anything
> about the value of this predicate, the predicate
> should be re-evaluated upon
> such return.
>
> If u can suggest any thread mailing groups also, It
> shall be of great usage.
> Regards
> Vikas
>
>
> ================================================
> To unsubscribe, send email to [EMAIL PROTECTED]
> with unsubscribe in subject header. Check archives
> at http://www.mail-archive.com/ilugd%40wpaa.org
>
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
================================================
To unsubscribe, send email to [EMAIL PROTECTED] with unsubscribe in subject header.
Check archives at http://www.mail-archive.com/ilugd%40wpaa.org
