default scheduler?

QNX DEVELOPERS Realtime and Embedded
1

hi,
how do I find which scheduler my host’s using?
during development on the IDE via “Debug Configuration” I can specify one of “SCHED_RR”, “SCHED_FIFO”, “SCHED_OTHER” per process but when I run the same binaries on the host I assume they’re using one of the above but I don’t know which.

The reason I ask is… I’m getting different behaviour when accessing IO protected by a semaphore depending on whether I run via the IDE or via a shell and I wondered if it was using a different scheduling policy?

cheers

Edit, I did it like this in my code: pthread_getschedparam(thread, &pol, &sp);
I’d still be interested in a shell way (ps/pidin ?) of looking it up, cheers

edit2,
In my IDE I’m specifying RR, but when I start the binaries directly on my host I appear to be using OTHER.

2

As far as I know, the shell always starts a process with SCHED_RR. Are you starting with something different from the IDE?

3

When using the IDE, the program is started by qconn.

Unless programaticaly controled, priority and policy are inherited from the parent.

To look the policy from the shell using pidin and check the letter beside the priority.

4

Cheers, because I’ve used the dev iso for my rte I think by default it’s sched_other. However, It looks like from the docs if I start a shell as rr my bins will inherit from that. Ultimately I’d have been better of setting up a proper rte. cheers

5

for anyone googling here, I derived my shell’s pid with $$, and then changed its priority and scheduler to 10r via the slay command.

I’m still getting different behaviour with my IO when I run with the IDE attached and when I run without and I’m not sure what else to try; since I’m running the same config, priorities and scheduler. The weird thing is my system behaves with the ide attached and misbehaves when it isn’t.

6

Years ago I used to run into this type of problem. I like to call these shy bugs because when you look for them, they hide. Something as benign as putting a printf in the right place can hide the problem.

My guess is that when you are running via the IDE, you are slowing things down which is hiding a race condition. I would skip the IDE for now and try the following. If you are running on a multi-core, set affinity for all threads to the same single processor. Then set each thread to a unique priority and see if the problem goes away. If it goes away, then you are right about the scheduler. If it stays, then it is something else.

7

QNX calls these bugs “Heisenbugs” in some of their recent whitepapers about safety critical software.

8

And to think I studied Quantum Mechanics in college and never thought of this.
Of course I didn’t use any of the following in the name of my company and or products:
Quantum, Photon, Neutrino, … what did I miss?

There’s another hidden meaning to this now for all you Breaking Bad fans.
Not only is a Heisenbug hard to find when you look for it, but over time it becomes a mean FM’r.

9

Isn’t it more like Schrödinger’s cat/bug? Observing it alters the behaviour?

The bug for the mo isn’t showing, I switched some mutex protected in house logging we were using for no-mutex slogger and the problem currently isn’t showing :slight_smile: cheers for the suggestions, I’m ‘guessing’ a mutex/thread priority problem which didn’t show when std err went to the IDE but did when it went to the console

Edit. Or is that h’s uncertainty principle?

10

Schrödinger’s cat is about the Copenhagen interpretation of quantum mechanics. Quantum mechanics tells you how to calculate the probability of an event, but doesn’t explain what is happening. In Schrödinger’s experiment, Quantum mechanics tells you that when you open the box, you have a 50% probability of finding a dead cat. It doesn’t tell what the state of the cat is between the time the trigger particle is detected and when you open the box. The Copenhagen interpretation is that the cat is somehow neither dead or alive. This seems absurd which is the reason that Schrödinger’s proposed the Gedanken experiment in the first place. The main alternative suggests that when the trigger particle is detected, the universe splits. In one universe the cat is dead and in the other it is alive. You find out which universe you are in by opening the box, but before you open the box the cat is not in an ambiguous state, you just don’t know what it is. Some find this idea even more absurd than Copenhagen, but some recent experiments suggest otherwise.

Heisenberg’s uncertainty principle is a direct consequence of Quantum mechanics that says that in the experiment that tries to detect one property of an object, eg. position, that another complementary property, momentum, becomes disturbed. In the case of a Heisenbug, the complementary properties are (probably) your knowledge of where the bug occurs, and circumstance that causes the bug. So you try to find where the bug is by putting in a printf or using the debugger, and the bug no longer occurs.

If a mutex solved your problem, you probably had a race condition.

11

You can`t really do that, by default process priority floats, that means when the program creates a pulse, which is given the priority of the program when the pulse is created (for example) if you change the priority of the process with slay, when that pulse is fired the program will float to the priority of the pulse.