Pulse based timer ?

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

I created a thread. I basically followed the example found on pg 42 of
the Krten book to set the priority to 20. Here’s a code extract:

…
pthread_attr_t threadParams;
pthread_attr_init(&threadParams);

pthread_attr_setinheritsched(&threadParams, PTHREAD_EXPLICIT_SCHED);
threadParams.param.sched_priority = 20;
if (pthread_create(NULL, &threadParams, (void*)doDrumThread, NULL)) {
perror(“startDrumRoll pthread_create”);
exit(EXIT_FAILURE);
…

The thread’s pretty simple. It sets up a pulse based timer, and then
goes into a forever loop waiting for periodic pulses:

int doDrumThread(void* ignored)
{
timer_t drumTimer;
struct sigevent pulseEvent;
struct itimerspec drumTickInterval;
int channelID, connectionID;
int result;
struct _pulse scratchPulse;

channelID = ChannelCreate(0);
if(channelID == -1) {
perror(“channel creation failed”);
exit(1);
}
connectionID = ConnectAttach(0, 0, channelID, 0, 0);
if(connectionID == -1) {
perror(“channel creation failed”);
exit(1);
}

SIGEV_PULSE_INIT(&pulseEvent, connectionID, 20, 1, 0);

if(timer_create(CLOCK_REALTIME, &pulseEvent, &drumTimer)) {
perror(“timer_create()”);
exit(1);
}

drumTickInterval.it_value.tv_sec = 0;
drumTickInterval.it_value.tv_nsec = 1000000;
drumTickInterval.it_interval.tv_sec = 0;
drumTickInterval.it_interval.tv_nsec = 1000000;

if(timer_settime(drumTimer, NULL, &drumTickInterval, NULL)) {
exit(1);
}

FOREVER {
result = MsgReceivePulse(channelID, &scratchPulse, sizeof(scratchPulse),
NULL);
if(result == 0) ratchetDrum();
}
return 0;
}

This is basically an evolution of the example Krten provides in the
Timers chapter. The problem I am having is with the third argument to
the SIGEV_PULSE_INIT macro. I had set it to
SIGEV_PULSE_PRIO_INHERIT. When I did this though and ran pidin, my drum
thread would always be at a priority of 10. When I changed the third
argument to match the priority of the drum thread, then pidin shows it
at 20 where I wanted it at. Why doesn’t SIGEV_PULSE_PRIO_INHERIT work?

BTW: It really annoys me that I can’t run this timer any faster than
this. Yes, I know, I can always run my program as root, and I can make a
call which allows me to go to at twice that. I wanted to run at 250
micros in the first place though. I thought this was a RealTime OS?

–
Travis Griggs (a.k.a. Lord of the Fries)
Member: 3rd Boolean State Software Collective
Key Technology
“It had better be a pretty good meeting to be better than no meeting at
all”-- Boyd K. Packer

2

Travis Griggs wrote:


This is basically an evolution of the example Krten provides in the
Timers chapter. The problem I am having is with the third argument to
the SIGEV_PULSE_INIT macro. I had set it to
SIGEV_PULSE_PRIO_INHERIT. When I did this though and ran pidin, my drum
thread would always be at a priority of 10. When I changed the third
argument to match the priority of the drum thread, then pidin shows it
at 20 where I wanted it at. Why doesn’t SIGEV_PULSE_PRIO_INHERIT work?

OK, I’ve discovered that SIGEV_PUSLE_PRIO_INHERIT does work; just not as
I would have expected (or would like). Apparently, this causes the pulse
to inherit the priority of the BASE process; the main thread. Even
though, the thread was created and cut loose at another priority. So
when you run it from the shell, it inherits the main thread priority of
10. If I execute the program with

nice -n-2 sorter

pidin shows the main thread and the pulse blocked thread running at 12.
Even though, the thread which sets up the pulse and then waits on it was
explicitely launched at 20. I don’t really why one would use the
SIGEV_PULSE_PRIO_INHERIT flag. Just set the priority of the pulse to the
same as the thread it was created in.

–
Travis Griggs (a.k.a. Lord of the Fries)
Member: 3rd Boolean State Software Collective
Key Technology
“It had better be a pretty good meeting to be better than no meeting at
all”-- Boyd K. Packer