Hi Frank,
I don’t think that a race condition contributes to the problem, because the first signal reception takes place after the call /tx.submit()/. Anyway, I made the suggested change (remove the thread start from the /Receiver/’s constructor and do it explicitly before the instantiation of /Signal_transmitter/), but again the signal was received twice.
yesterday prior answering your email, I was able to reproduce the superfluous wakeup on Linux using the code snippets you provided. After fixing the race condition, the superfluous wakeup does longer occur with my test case. Today, I tested both variants (race, no race) on OKL4_x86 and the superfluous wakeup never occurs here. For your convenience, I have attached my test program to this email.
I checked the properties of the signal, and indeed, as you supposed, on the first reception the parameter /num/ has the value *0*, while on the second reception the value is *1*. This would allow to ignore the unwanted signal as a temporary workaround, but the observed behaviour
Evaluating the 'num' value of the returned signal should not be a temporary workaround - it is the only correct way to use the API if the exact number of occurred signals are of importance to you.
casts some doubt on the reliability of the signalling mechanism. There might by other situations where the signal is not at all received although it was sent once.
Please do not hesitate to substantiate this claim. I'm more than happy about bug reports and test cases. Sharing your gut feeling with us does not contribute to improve the framework though. .-)
Regards Norman