In reply to elmar:
Elmar,
Sorry, sometimes in my Mentor division use “0-time function call” as
a synonym for a non-blocking, i.e. “instantaneous” call. But looking at
IEEE 1666 I realize that you are correct that peek() itself is blocking.
I had not looked at this for awhile and was thinking that peek()'ing is
just an instantaneous non-blocking call.
OK, so reviewing the meaning of peek() in the LRM it must wait until
the next transaction on the fifo, then return its value without removing
it (as get() does).
And indeed it looks like ::get() itself does already call wait_connected()
as your fix suggests. So it appears that we need to do the same in
peek().
I think the issue is that, although peek() itself is already blocking
on the m_sem member, the problem is that semaphore is not is not created
in the first place until it is connected. So it stands to reason that we
need to call wait_connect() as ::get() does and as you suggest.
We will file a bug report on this and put this fix in for
the 2.3.1 release.
Thanks very much for your feedback.
– johnS