# WaitableEvent Posix impl

**URL:** <https://forum.juce.com/t/waitableevent-posix-impl/2190>\
**Category:** General JUCE discussion\
**Created:** [October 17, 2007, 3:30pm UTC](https://forum.juce.com/t/waitableevent-posix-impl/2190 "2007-10-17T15:30:48Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![otristan](https://avatars.discourse-cdn.com/v4/letter/o/f0a364/32.png) [@otristan](https://forum.juce.com/u/otristan)\
**Post date:** [October 17, 2007, 3:30pm UTC](https://forum.juce.com/t/waitableevent-posix-impl/2190/1 "2007-10-17T15:30:48Z")

</div>

Hi Jules,

According to the docs and the windows impl, WaitableEvent should wake all the waiting thread.  
Problem is, the pthread version use pthread\_cond\_signal  
instead of pthread\_cond\_broadcast.

Is this intended ?

What about adding a signalAndReset function too (equivalent to PulseEvent on Win32 and default pthread\_cond\_broadcast impl)

Thanks,

---

<div class="post-metadata">

**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\
**Post date:** [October 17, 2007, 3:54pm UTC](https://forum.juce.com/t/waitableevent-posix-impl/2190/2 "2007-10-17T15:54:50Z")

</div>

ah - you’re right, it should be using pthread\_cond\_broadcast… Doh! Thanks for letting me know!

And I’ll make a note to do a signalAndReset too…

---

<div class="post-metadata">

**Author:** ![X-Ryl669](https://avatars.discourse-cdn.com/v4/letter/x/a5b964/32.png) [@X-Ryl669](https://forum.juce.com/u/X-Ryl669)\
**Post date:** [October 18, 2007, 8:04am UTC](https://forum.juce.com/t/waitableevent-posix-impl/2190/3 "2007-10-18T08:04:34Z")

</div>

Take care that PulseEvent under Windows is flawed.  
Unlike pthread, if a thread has not reached the waiting point while another pulse the event, then it’ll never see that the event was pulsed, and will deadlock.

See [why PulseEvent is fundamentally flawed](http://blogs.msdn.com/oldnewthing/archive/2005/01/05/346888.aspx)

pthread\_cond\_signal is like PulseEvent in a way, and should be avoided too.

---

<div class="post-metadata">

**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\
**Post date:** [October 18, 2007, 8:47am UTC](https://forum.juce.com/t/waitableevent-posix-impl/2190/4 "2007-10-18T08:47:04Z")

</div>

That is quite nasty. What’s the rationale for needing pulseevent anyway? I don’t think I’ve ever written anything where it would have been useful?..

---

<div class="post-metadata">

**Author:** ![otristan](https://avatars.discourse-cdn.com/v4/letter/o/f0a364/32.png) [@otristan](https://forum.juce.com/u/otristan)\
**Post date:** [October 22, 2007, 8:17am UTC](https://forum.juce.com/t/waitableevent-posix-impl/2190/5 "2007-10-22T08:17:21Z")

</div>

It s not because you need to handle it with care that there is no use.

PulseEvent is not flawed it’s just the way it works. you have the same issue  
with pthread\_cond\_signal and pthread\_cond\_broadcast  
if you don’t have a flag.

If it’s not the behavior you want, then don’t use it.

If it was not useful then I wonder why windows and posix have implemented it 🙂

You may want to use PulseEvent if you already handle on your own the on/off flag.

---

<div class="post-metadata">

**Author:** ![X-Ryl669](https://avatars.discourse-cdn.com/v4/letter/x/a5b964/32.png) [@X-Ryl669](https://forum.juce.com/u/X-Ryl669)\
**Post date:** [October 22, 2007, 8:43am UTC](https://forum.juce.com/t/waitableevent-posix-impl/2190/6 "2007-10-22T08:43:48Z")

</div>

The issue with Windows’s PulseEvent is that, even if a thread is stopped and waiting for the event, the Kernel can borrow it to make it perform some APC work, while at the same time, still allow the event to be pulsed. When this happens, your thread doesn’t see the event, and your application is deadlocked (your main thread thinks it has unblocked the other thread, while the other thread hasn’t finished waiting)

This means that your software will “work” 99.99999% of the case like expected, but it’s gonna break, of course in one of the major customer, and you’ll be unlikely to suspect the PulseEvent code.

Sadly we need the software to perfom deterministically every time.

It’s not the case with POSIX synchronization primitives through.

---

<div class="post-metadata">

**Author:** ![otristan](https://avatars.discourse-cdn.com/v4/letter/o/f0a364/32.png) [@otristan](https://forum.juce.com/u/otristan)\
**Post date:** [October 22, 2007, 9:04am UTC](https://forum.juce.com/t/waitableevent-posix-impl/2190/7 "2007-10-22T09:04:33Z")

</div>

oki doki.

My point was more about adding signalAndReset than the way it would be implemented 🙂

In that case you can still implement it using SetEvent and ResetEvent on windows.

Thanks,

---

<div class="post-metadata">

**Author:** ![ptomaine](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/ptomaine/32/245_2.png) [@ptomaine](https://forum.juce.com/u/ptomaine)\
**Post date:** [October 22, 2007, 9:35am UTC](https://forum.juce.com/t/waitableevent-posix-impl/2190/8 "2007-10-22T09:35:49Z")

</div>

[quote=“otristan”]oki doki.

In that case you can still implement it using SetEvent and ResetEvent on windows.

[/quote]

SetEvent and ResetEvent won’t help! 🙂

read this [http://support.microsoft.com/?id=173260](http://support.microsoft.com/?id=173260)

(honestly, I think this shit happens not only in the debug mode)

---

<div class="post-metadata">

**Author:** ![X-Ryl669](https://avatars.discourse-cdn.com/v4/letter/x/a5b964/32.png) [@X-Ryl669](https://forum.juce.com/u/X-Ryl669)\
**Post date:** [October 22, 2007, 10:11am UTC](https://forum.juce.com/t/waitableevent-posix-impl/2190/9 "2007-10-22T10:11:14Z")

</div>

The only solution that’ll work everytime is :  
[list]  
[_] The main thread call SetEvent on a manual reset event[/_]  
[_] The other thread simply “WaitForSingleObject” on the event[/_]  
[_] The other thread call ResetEvent when it got the signaled object information (regardless of kernel APC, as it’s manual reset, the event is signaled until a thread reset it)[/_][/list]

However, this means that you must have 1 event per thread, and possibly a CriticalSection protected/Atomic counter (that’s the way it’s done in .NET framework with their PulseAll method).

You can have a look to the openpthread solution for their condition variable that is immune to this.

---

<div class="post-metadata">

**Author:** ![otristan](https://avatars.discourse-cdn.com/v4/letter/o/f0a364/32.png) [@otristan](https://forum.juce.com/u/otristan)\
**Post date:** [October 22, 2007, 10:14am UTC](https://forum.juce.com/t/waitableevent-posix-impl/2190/10 "2007-10-22T10:14:57Z")

</div>

Well if it happened without the debugger too, I don t think you ll be able  
to do reliable threaded apps on windows.  
And I don t think that the case.  
(No troll please)

So the issue with PulseEvent is only in the debugger. Not a big deal then.  
If you relied on the debugger to debug thread logic you already screwed.

Thanks for the information.

---

<div class="post-metadata">

**Author:** ![X-Ryl669](https://avatars.discourse-cdn.com/v4/letter/x/a5b964/32.png) [@X-Ryl669](https://forum.juce.com/u/X-Ryl669)\
**Post date:** [October 22, 2007, 10:33am UTC](https://forum.juce.com/t/waitableevent-posix-impl/2190/11 "2007-10-22T10:33:45Z")

</div>

> [@](#):
>
> honestly, I think this shit happens not only in the debug mode

Ptdomaine is quite right here.  
This happens when the kernel plays APC with your threads.  
This means everytime another process calls ReadProcessMemory (like any AV scan does), or SuspendThread / ResumeThread / CreateRemoteThread, or when an “hardware” interrupt happens (like unplugging a USB device you might be using), or the first time you call TlsAlloc and so on.

Sure, it doesn’t shows up 100% of the time, probably not even 0.1% of times, but it CAN happen, so that it’s a road I wouldn’t go on anyway.

BTW, if I know this, it’s because it happened in our main software (which runs 24/7), and the crash dump they send was unexplainable unless such behaviour occurs (a thread was still waiting for a signaled event while the main thread continued, making the main thread waiting for the other thread’s work and “jobDone” event which never happened =\> deadlock).

In all cases, you can do whatever you want…[/quote]

---

<div class="post-metadata">

**Author:** ![otristan](https://avatars.discourse-cdn.com/v4/letter/o/f0a364/32.png) [@otristan](https://forum.juce.com/u/otristan)\
**Post date:** [October 22, 2007, 10:47am UTC](https://forum.juce.com/t/waitableevent-posix-impl/2190/12 "2007-10-22T10:47:47Z")

</div>

I really like it when you can’t trust the OS anymore 🙂

Thanks for the information.

---

<div class="post-metadata">

**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\
**Post date:** [May 12, 2017, 10:06am UTC](https://forum.juce.com/t/waitableevent-posix-impl/2190/13 "2017-05-12T10:06:28Z")

</div>

Closed on May 12, 2017, 10:06am UTC


