Skip navigation.
Home
The QNX Community Portal

View topic - QNX OS Race Conditions

Page 1 of 1

QNX OS Race Conditions

PostPosted: Wed May 06, 2015 5:20 pm
by bhaskara-r
Please Help me how to find the
1.Timing Periods
2. Timing issues
3.Race conditions in the QNX OS ??

Re: QNX OS Race Conditions

PostPosted: Thu May 07, 2015 3:13 pm
by Tim
Your questions are too open ended.

Can you elaborate on what you want for each of these 3 things (are you trying to debug something or are you looking for theoretical answers).

Tim

Re: QNX OS Race Conditions

PostPosted: Fri May 08, 2015 5:16 am
by bhaskara-r
Hi tim,

I am trying to Debug my application which is running in QNX OS.

in that i want to find out the Race conditions and timing Periods.

How to start that... or else how to find out the race conditions..

or else please explain me what is race condition in QNX OS ??

Re: QNX OS Race Conditions

PostPosted: Fri May 08, 2015 4:46 pm
by Tim
A race condition in QNX is the same as it is anywhere else.

http://en.wikipedia.org/wiki/Race_condition

By timing periods do you mean the time slice allotted to processes/threads?

It would help if you described the problem you are seeing.

Tim

Re: QNX OS Race Conditions

PostPosted: Sat May 09, 2015 6:21 pm
by maschoen
I think your point of view is curious. People usually don't look for race conditions. Usually they are looking to fix a bug, and at the end of a trying debugging session where the bug seems to come and go, even disappear when searched for, they suspect a race condition. At that point it's usually fairly easy to identify.

Assuming for a second that you think that you have a race condition in a multi-threaded application, QNX provides a tool to verify this. First limit your process to one processor. You can do this by setting the run mask with the ThreadCtl() routine. If you were running on a multi-processor system, this may make the bug less common, but it still won't go away. Then change the scheduling method to FIFO. This will prevent one thread from running until the other is blocked. If this makes the bug go away, it was most definitely a race condition.

Of course it is possible to have a inter-process race condition. You could put in logging when processes send and receive but that could make a race condition disappear. In that case, if it is easy and fast to reproduce you could try using the kernel trace logger.