Pidin and MUTEX Info

bridged with qdn.public.qnxrtp.os
Post Reply
Stephane Grenier

Pidin and MUTEX Info

Post by Stephane Grenier » Mon Nov 17, 2003 2:21 pm

Hi All!

I am looking for info on what the number coming out of the pidin mean,
especially for the MUTEX. When I do a pidin and there is a process waiting
for a mutex, you get the following:

pid tid name prio STATE Blocked
94219 1 nectionmanager.exc 10r NANOSLEEP
192532 1 in/eslservices.exc 10r NANOSLEEP
192532 2 in/eslservices.exc 10f SEM 827ef08
192533 1 /emitterloader.exc 12r SEM 8175e24
192533 2 /emitterloader.exc 20r MUTEX 192534-02 #-2147
192533 3 /emitterloader.exc 27f INTR
192534 1 bur/bin/motion.exc 10r SEM 819be7c
192534 2 bur/bin/motion.exc 11r READY
192535 1 alibur/bin/doa.exc 12r SEM 817065c

In the blocked section the first part is the pid and thread number of the
process that has the mutex, but what I want to know is what is #-2147. Can
this part be use to setup each mutex with a unique Id, and if so how.

Cheers and Thanks!, Steph

David Gibbs

Re: Pidin and MUTEX Info

Post by David Gibbs » Mon Nov 17, 2003 5:30 pm

Stephane Grenier <sgrenier@excalibur-idt.com> wrote:
Hi All!

pid tid name prio STATE Blocked
94219 1 nectionmanager.exc 10r NANOSLEEP
192532 1 in/eslservices.exc 10r NANOSLEEP
192532 2 in/eslservices.exc 10f SEM 827ef08
192533 1 /emitterloader.exc 12r SEM 8175e24
192533 2 /emitterloader.exc 20r MUTEX 192534-02 #-2147
192533 3 /emitterloader.exc 27f INTR
192534 1 bur/bin/motion.exc 10r SEM 819be7c
192534 2 bur/bin/motion.exc 11r READY
192535 1 alibur/bin/doa.exc 12r SEM 817065c

In the blocked section the first part is the pid and thread number of the
process that has the mutex, but what I want to know is what is #-2147. Can
this part be use to setup each mutex with a unique Id, and if so how.
On my system (6.2.1B), that value is the count of how many times the
mutex has been locked. Normally, it was 1. If I created a recursive
mutex and locked it several times, that value counted upwards with
each lock.

Given what I've seen, -2147 is a very odd value.

What version of QNX are you running?

-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Stephane Grenier

Re: Pidin and MUTEX Info

Post by Stephane Grenier » Mon Nov 17, 2003 6:00 pm

Using 6.1A

Cheers!, Steph


"David Gibbs" <dagibbs@qnx.com> wrote in message
news:bpb0k3$sus$1@nntp.qnx.com...
Stephane Grenier <sgrenier@excalibur-idt.com> wrote:
Hi All!

pid tid name prio STATE Blocked
94219 1 nectionmanager.exc 10r NANOSLEEP
192532 1 in/eslservices.exc 10r NANOSLEEP
192532 2 in/eslservices.exc 10f SEM 827ef08
192533 1 /emitterloader.exc 12r SEM 8175e24
192533 2 /emitterloader.exc 20r MUTEX 192534-02 #-2147
192533 3 /emitterloader.exc 27f INTR
192534 1 bur/bin/motion.exc 10r SEM 819be7c
192534 2 bur/bin/motion.exc 11r READY
192535 1 alibur/bin/doa.exc 12r SEM 817065c

In the blocked section the first part is the pid and thread number of
the
process that has the mutex, but what I want to know is what is #-2147.
Can
this part be use to setup each mutex with a unique Id, and if so how.

On my system (6.2.1B), that value is the count of how many times the
mutex has been locked. Normally, it was 1. If I created a recursive
mutex and locked it several times, that value counted upwards with
each lock.

Given what I've seen, -2147 is a very odd value.

What version of QNX are you running?

-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Colin Burgess

Re: Pidin and MUTEX Info

Post by Colin Burgess » Mon Nov 17, 2003 6:32 pm

There was a bug in pidin that was fixed in 6.2.1, the count should
be masked with _NTO_SYNC_COUNTMASK (0x0fffffff)

Stephane Grenier <sgrenier@excalibur-idt.com> wrote:
Using 6.1A

Cheers!, Steph
"David Gibbs" <dagibbs@qnx.com> wrote in message
news:bpb0k3$sus$1@nntp.qnx.com...
Stephane Grenier <sgrenier@excalibur-idt.com> wrote:
Hi All!

pid tid name prio STATE Blocked
94219 1 nectionmanager.exc 10r NANOSLEEP
192532 1 in/eslservices.exc 10r NANOSLEEP
192532 2 in/eslservices.exc 10f SEM 827ef08
192533 1 /emitterloader.exc 12r SEM 8175e24
192533 2 /emitterloader.exc 20r MUTEX 192534-02 #-2147
192533 3 /emitterloader.exc 27f INTR
192534 1 bur/bin/motion.exc 10r SEM 819be7c
192534 2 bur/bin/motion.exc 11r READY
192535 1 alibur/bin/doa.exc 12r SEM 817065c

In the blocked section the first part is the pid and thread number of
the
process that has the mutex, but what I want to know is what is #-2147.
Can
this part be use to setup each mutex with a unique Id, and if so how.

On my system (6.2.1B), that value is the count of how many times the
mutex has been locked. Normally, it was 1. If I created a recursive
mutex and locked it several times, that value counted upwards with
each lock.

Given what I've seen, -2147 is a very odd value.

What version of QNX are you running?

-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.


--
cburgess@qnx.com

David Gibbs

Re: Pidin and MUTEX Info

Post by David Gibbs » Mon Nov 17, 2003 6:41 pm

Stephane Grenier <sgrenier@excalibur-idt.com> wrote:
Using 6.1A
Dunno what it showed back then, but it won't be useful for what you
were asking -- assigning each mutex a unique id.

I assume you're trying to resolve the "it's blocked on a mutex, which
one is it?" question.

*caveat* the following is based on 6.2.1B headers, but the information
should not have changed.

You might have to write your own code to get this information -- if
you take a look at:

<sys/procfs.h> and
<sys/debug.h>

You will find there is _debug_thread_info structure in <sys/debug.h> that
can be gotten from procnto by a devctl() given in <sys/procfs.h>.

It has a union of "blocked on" information, including a sync element, with
a _Uintptrt sync, this is, I THINK, the virtual address in the process of
the synch object (e.g.) mutex on which it is blocked.

I think pidin takes this, looks at the synch object itself, and uses the
data within the synch object to give you the owning pid/tid.

For your purpose, the actual virtual address is more useful. You should
be able (with some prep work, such as storing away the virtual address
of the shared memory object in which the mutex resides, and knowing the
internal layout of that shared memory object) be able to figure out which
mutex is the one.

(Or, you could look at the source to pidin (6.1.1) on cvs.qnx.com, but
I'll warn you that it is somewhat opaque.)

-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Post Reply

Return to “qdn.public.qnxrtp.os”