Discovered that using recursive mutexes with condition variables caused
Neutrino to hang (or at least appear to hang for all practical purposes).
I avoided the problem by not using recursive mutexes but seems that the
kernel shouldn’t appear to hang? Might want to check into this behavior.
BTW: I was not running as root and didn’t request any special priviledges
via ThreadCtl.
Dave Lynott <david.lynott@csipros.com> wrote:
Discovered that using recursive mutexes with condition variables caused
Neutrino to hang (or at least appear to hang for all practical purposes).I avoided the problem by not using recursive mutexes but seems that the
kernel shouldn’t appear to hang? Might want to check into this behavior.
BTW: I was not running as root and didn’t request any special priviledges
via ThreadCtl.
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
First time I’ve seen you speechless Chris! 
Kevin
“Chris McKillop” <cdm@qnx.com> wrote in message
news:bls676$ouc$1@nntp.qnx.com…
Dave Lynott <> david.lynott@csipros.com> > wrote:
Discovered that using recursive mutexes with condition variables caused
Neutrino to hang (or at least appear to hang for all practical
purposes).I avoided the problem by not using recursive mutexes but seems that the
kernel shouldn’t appear to hang? Might want to check into this behavior.
BTW: I was not running as root and didn’t request any special
priviledges
via ThreadCtl.
\Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
Dave Lynott <david.lynott@csipros.com> wrote:
Discovered that using recursive mutexes with condition variables caused
Neutrino to hang (or at least appear to hang for all practical purposes).
You can’t use recursive mutexes with condvars. This is documented
somewhat in the pthread_cond_*() docs (with a finger-pointy thing).
Did you check the return values, are you sure it isn’t EINVAL?
Yep, I saw the finger icon in the docset…
I fixed the problem per the documentation. I don’t remember what it
returned… I believe it does return an error. The problem is that using it
afterwards should not cause the kernel to “appear” to hang. I would have
expected a segmentation fault (or even peculiar behavior within the app) but
it looked like it caused a bit more trouble than that.
When I say it “appeared” to hang, Photon was not responding to events. It
could be something regarding priority. I would have been running at priority
10. There are a lot of things running at that priority so perhaps Photon was
just not getting a chance to run? I didn’t investigate that fully… found
my problem reading the QNX docs and solved it. I was porting some code that
seemed to work under solaris and cygwin’s Posix emulation library. They
seemed to need the recursive mutex to accomplish what I was trying to do
(signal a condition from signal handler and wait for it in the main
program). Even without the recursive mutex, Neutrino behaves like I would
have expected. The only docs I’ve been able to find regarding not using
recursive mutexes with condition variables are the QNX ones? Is this one of
those gray areas within the Posix spec?
“John Garvey” <jgarvey@qnx.com> wrote in message
news:blskao$50o$1@nntp.qnx.com…
Dave Lynott <> david.lynott@csipros.com> > wrote:
Discovered that using recursive mutexes with condition variables caused
Neutrino to hang (or at least appear to hang for all practical
purposes).You can’t use recursive mutexes with condvars. This is documented
somewhat in the pthread_cond_*() docs (with a finger-pointy thing).
Did you check the return values, are you sure it isn’t EINVAL?
Dave Lynott <david.lynott@csipros.com> wrote:
I fixed the problem per the documentation. I don’t remember what it
returned… I believe it does return an error. The problem is that
I was thinking that perhaps it was your code that was spinning at
high priority following the failure to wait/signal the condvar
because of the EINVAL mutex … :-/ (the illusion of hang time 
Even without the recursive mutex, Neutrino behaves like I would
have expected. The only docs I’ve been able to find regarding not using
recursive mutexes with condition variables are the QNX ones? Is this one of
those gray areas within the Posix spec?
POSIX does not define recursive mutexes (except to note under
pthread_mutexattr_init() that it is an example of a potential
attribute extension that is not yet widely agreed to be useful).
Personally I view a recursive mutex (or the need for one) as
bad design: the critical region protected by the mutex should
be self-contained/tight/small enough that re-entrancy concerns
do not arise …