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.
The restriction is elsewhere. pthread_cond_signal() is not in the list of
async-signal-safe func
Hi,
thanks for your responses. Yes, upon more reading I realized mixing signals
with pthread mutexes was not safe. I guess
I was getting a race condition inside the mutex locking.
As a workaround, I resorted to using SIGEV_THREAD notification for POSIX
timers. This appears to work and I guess it
Just beware of https://github.com/apache/incubator-nuttx/issues/1352
On 1/13/2021 8:09 AM, Matias N. wrote:
Hi,
thanks for your responses. Yes, upon more reading I realized mixing
signals with pthread mutexes was not safe. I guess
I was getting a race condition inside the mutex locking.
As a
Thanks. I'm using FLAT mode so no problem.
Best,
Matias
On Wed, Jan 13, 2021, at 11:40, Gregory Nutt wrote:
> Just beware of https://github.com/apache/incubator-nuttx/issues/1352
>
> On 1/13/2021 8:09 AM, Matias N. wrote:
>> Hi,
>> thanks for your responses. Yes, upon more reading I realized mix
We have surpassed our 40,000th commit in the main NuttX repository.
Many thanks to all of our past and present contributors who helped get
us this far over the years.
Here's to the next 40,000 commits!
Cheers,
Nathan
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
Cheers!
On Wed, Jan 13, 2021 at 10:37 PM Nathan Hartman
wrote:
>
> We have surpassed our 40,000th commit in the main NuttX repository.
>
> Many thanks to all of our past and present contributors who helped get
> us this far over the years.
>
> Here's to the next 40,000 commits!
>
> Cheers,
> Nath
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:
>
> >