Thanks Greg for the insight into the problem. The fact that the signal handler
runs in the same thread was not something I thought. Also I think it confirms
using
SIGEV_THREAD for this is the safe approach in this scenario.
Best,
Matias
On Wed, Jan 13, 2021, at 19:06, Gregory Nutt wrote:
>
> >
I am thinking that there must be some race condition: When the
condition variable is created the cond->sem value will be set to
zero. While waiting for cond->sem, it will be set to -1. If you see
cond->sem equal to zero, my guess would be that the signal was
received and cond->sem was incre
hronous signal handler can get called between any
>>> two instructions so safe synchronization with condition variables might be
>>> hard to implement. Use semaphores and sem_post() instead.
>>>
>>> -Juha
>>>
>>>
>>>
>>> *From:
Sent:* Wednesday, January 13, 2021 4:24 AM
*To:* dev@nuttx.apache.org
*Subject:* Re: condition variables and signals
BTW, looking at the spec for pthread_cond_wait, there's actually no
mention about a limitation regarding using pthread_cond_signal
invoked from within a signal handler to unbloc
ment. Use semaphores and sem_post() instead.
>
> -Juha
>
>
>
> *From:* Gregory Nutt
> *Sent:* Wednesday, January 13, 2021 4:24 AM
> *To:* dev@nuttx.apache.org
> *Subject:* Re: condition variables and signals
>
>
>> BTW, looking at the spec for pthread_con
ition variables might be hard to
implement. Use semaphores and sem_post() instead.
-Juha
From: Gregory Nutt
Sent: Wednesday, January 13, 2021 4:24 AM
To: dev@nuttx.apache.org
Subject: Re: condition variables and signals
BTW, looking at the spec for pthread_cond
BTW, looking at the spec for pthread_cond_wait, there's actually no
mention about a limitation regarding using pthread_cond_signal invoked
from within a signal handler to unblock a pthread_cond_wait. However,
this does not work
either for me. If you follow the signal operation, I can see that
> Note that I was initially signaling the condition variable from within the
> signal handler but this did not work either. However, looking at pthread
> documentation this is supposedly not supported:
> https://linux.die.net/man/3/pthread_cond_signal
> (I'm not sure if that really applies to N
Ahh ok. Thanks for that, should've looked further into the spec. I assumed from
other documentation I read that it could work.
So, now I'm a bit stuck on mixing the signal-based POSIX timers with mutexes. I
will see about other synchronization mechanism.
Best,
Matias
On Tue, Jan 12, 2021, at 2
pthread_cond_wait() is not supposed to return if a signal is received:
https://pubs.opengroup.org/onlinepubs/009696699/functions/pthread_cond_wait.html
EINTR is not one of the valid return values from pthread_cond_wait().
This is the specific POSIX requirement that must be followed: "If a
I'm not expecting the task to be killed, but the pthread_cond_wait to return
when the process receives a signal (which I'm handling in a signal handler).
What I need is to exit the pthread_cond_wait upon reception of the signal. As I
mentioned, doing pthread_cond_signal from the handler did
The wait I'm referring to is the one on the semaphore underlying to the condition
variable (pthread_sem_take on cond->sem). This ends up as a call to
nxsem_wait_uninterruptible which loops on the wait to ignore EINTR errors. So I
understand that a signal would not interrupt the wait (and thu
I'm not expecting the task to be killed, but the pthread_cond_wait to return
when the process receives a signal (which I'm handling in a signal handler).
What I need is to exit the pthread_cond_wait upon reception of the signal. As I
mentioned, doing pthread_cond_signal from the handler did not
The wait I'm referring to is the one on the semaphore underlying to the
condition variable (pthread_sem_take on cond->sem). This ends up as a call to
nxsem_wait_uninterruptible which loops on the wait to ignore EINTR errors. So I
understand that a signal would not interrupt the wait (and thus, t
I'm having an issue when waiting on a pthread condition variable from
the main thread and then a signal handler runs, which should cancel
the wait since I have cancellation points enabled, however this did
not happen.
I don't understand this either. A signal will not, in general, cause a
I'm having an issue when waiting on a pthread condition variable from
the main thread and then a signal handler runs, which should cancel
the wait since I have cancellation points enabled, however this did
not happen. While debugging I see the main thread blocked when
standing inside the sig
As a quick test, I made pthread_cond_wait call to pthread_sem_take
with the last argument to true (which then use the interruptible
version) and it now cancels the wait. So it would seem that this is a
bug right?
nxsem_wait_uninterruptible() should have no effect on thread
cancellation (i.e
As a quick test, I made pthread_cond_wait call to pthread_sem_take with the
last argument to true (which then use the interruptible version) and it now
cancels the wait. So it would seem that this is a bug right?
Best,
Matias
On Tue, Jan 12, 2021, at 20:13, Matias N. wrote:
> Hi,
> I'm having a
18 matches
Mail list logo
