Hi,
I’m quite new to QNX. I’ve got a few processes
sharing data. To prevent multiple access and
undefined altering of the variables I use a Mutex.
It happens that I have to kill a process. The Systems
shut down an other process prompting “mutex deadlock
(core dumped)”. What is the reason for this message?
Thanks
Michael
Hi Michael…
I am in no way an expert, but some pointers…
Regards…
Miguel.
Michael wrote:
Hi,
I’m quite new to QNX. I’ve got a few processes
sharing data. To prevent multiple access and
undefined altering of the variables I use a Mutex.It happens that I have to kill a process. The Systems
shut down an other process prompting “mutex deadlock
(core dumped)”. What is the reason for this message?Thanks
Michael
What are you complaining about? You created a deadlock,
and the OS detected it. That’s what’s supposed to happen.
That beats the traditional UNIX “hung waiting for lock
file that will never be deleted”, doesn’t it?
John Nagle
Michael wrote:
Hi,
I’m quite new to QNX. I’ve got a few processes
sharing data. To prevent multiple access and
undefined altering of the variables I use a Mutex.It happens that I have to kill a process. The Systems
shut down an other process prompting “mutex deadlock
(core dumped)”. What is the reason for this message?Thanks
Michael
Hi John,
Thanks, no complains, just a big “?” 
If this is the meaning of “mutex deadlock” its
fine, then I know the problem. I just wonder if
there might be an other conflict causing this error.
So qnx is able to detect the unfreed mutex and that
there is no way out.
Thanks to all of you
Michael
John Nagle wrote:
What are you complaining about? You created a deadlock,
and the OS detected it. That’s what’s supposed to happen.That beats the traditional UNIX “hung waiting for lock
file that will never be deleted”, doesn’t it?John Nagle
Hi Miguel,
I am the originator of the mutex problem, so I might reply on this.
- where does the mutex live?
It lives in shared memory .
- do an orderly shutdown where you are
at a point where you do not hold the mutex
This is sometimes not possible. Due to the application, termination of
processes with CTRL-C is sometimes necessary (especially during
development). So I am looking for a mechanism to free the mutex after (or
while) terminating the mutex-owning process, so the other waiting processes
are not terminated as well.
- how do you handle mutex init?
The init for shared memory seems to be OK. There is no fault during normal
operation until a CTRL-C occurs.
- post your code so others can help…
Here you are ( it is just the normal mutex condition wait function that
returns the mutex deadlock message when an other process that has the mutex
is terminated by CTRL-C ):
pthread_mutex_lock( &(pTokenCondition->mutex) );
while (! (pTokenCondition->token ==
sCommConfig.ulThreadIdentity ) )
{
pthread_cond_wait(
&(pTokenCondition->condvar),
&(pTokenCondition->mutex) );
Regards
Nnamdi
michael <mic457@gmx.net> wrote:
m > Hi John,
m > Thanks, no complains, just a big “?”
m > If this is the meaning of “mutex deadlock” its
m > fine, then I know the problem. I just wonder if
m > there might be an other conflict causing this error.
m > So qnx is able to detect the unfreed mutex and that
m > there is no way out.
m > Thanks to all of you
m > Michael
You might want to register an atexit() function right after you acquire
the mutex. If you Ctrl-C the program it should call any registered
atexit() regstered functions.
In your atexit() function, test that you still own teh mutex, and if so,
release it. Then it is safe to exit.
“Nnamdi Kohn” <nnamdi.kohn@web.de> wrote in message
news:c1f8ti$hqt$1@inn.qnx.com…
Hi Miguel,
I am the originator of the mutex problem, so I might reply on this.
- where does the mutex live?
It lives in shared memory .
- do an orderly shutdown where you are
at a point where you do not hold the mutexThis is sometimes not possible. Due to the application, termination of
processes with CTRL-C is sometimes necessary (especially during
development). So I am looking for a mechanism to free the mutex after (or
while) terminating the mutex-owning process, so the other waiting
processes
are not terminated as well.
- how do you handle mutex init?
The init for shared memory seems to be OK. There is no fault during normal
operation until a CTRL-C occurs.
Take a look at the docs for pthread_cleanup_push/pop handlers to cleanup
things like mutexes/memory/cleanup as well as SyncMutexEvent() in order to
revive a dead mutex.
–
Cheers,
Adam
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
Hello Bill,
You might want to register an atexit() function right
after you acquire the mutex. If you Ctrl-C the
program it should call any registered atexit()
regstered functions.In your atexit() function, test that you still own
teh mutex, and if so, release it. Then it is safe to exit.
I’ve tried this, but the function “installed” by atexit() is just executed
at “normal” program termination (like exit()), not when the termination is
done with CTRL-C.
Nnamdi Kohn <nnamdi.kohn@web.de> wrote:
NK > Hello Bill,
You might want to register an atexit() function right
after you acquire the mutex. If you Ctrl-C the
program it should call any registered atexit()
regstered functions.In your atexit() function, test that you still own
teh mutex, and if so, release it. Then it is safe to exit.
NK > I’ve tried this, but the function “installed” by atexit() is just executed
NK > at “normal” program termination (like exit()), not when the termination is
NK > done with CTRL-C.
OK. Sorry. Then you will have to trap the signal generated by Ctrl-C
and call your ending function yourself…