First, I must say that this all concernes quite current
CURRENT (Jan 9 or so). I don't know if the same holds for
I'm kind of puzzled.
I've a simple sample program (see at the bottom). It creates 10
threads with start function start_my_thread(), and then runs the
same function in main(). So, we have 11 threads doing the same job.
Function start_my_thread() just increments indefinitely counters
(each thread has its own counter).
Program, when killed with SIGINT, prints all counters and exits.
Now, as I understand, userspace threads in FreeBSD are preemptive.
So, though my 11 threads are all computational and do not do
any syscalls, sleeps, sched_yield, whatever -- newertheless,
the program should not be stuck in one thread. And it seems to
be sometimes true. But only sometimes!
Depending on the phase of the moon (it seems) sometimes my
program gives (after ^C):
Thread 0x00: 0
Thread 0x01: 0
Thread 0x02: 0
Thread 0x03: 0
Thread 0x04: 0
Thread 0x05: 0
Thread 0x06: 0
Thread 0x07: 0
Thread 0x08: 0
Thread 0x09: 0
Thread 0x0a: 488133092
Which means that the main thread takes all the time. In the same
time 'ps -o command,sigcatch,nsignals,sig' gives:
COMMAND CAUGHT NSIGS PENDING
./a.out 14080002 358 0
I suppose that means that the program has a handler for SIGPROF
installed (which I know is used to preempt threads). And the number
of delivered signals steadily goes up (which I suppose means that
SIGPROF's are actually delivered to program -- or else where does
that number of signals come from?).
Again, depending on the phase of the moon, sometimes program gives
quite normal result (from my point of view):
Thread 0x00: 45894831
Thread 0x01: 42657716
Thread 0x02: 44529528
Thread 0x03: 45732187
Thread 0x04: 41087510
Thread 0x05: 39383485
Thread 0x06: 40748919
Thread 0x07: 39539107
Thread 0x08: 41414655
Thread 0x09: 38647395
Thread 0x0a: 43215354
This result is obtained for approximately the same runtime of the
program. The same picture from 'ps'. I'm starting to beleive that
the behaviour is dependent on the moon because two types of that
behaviour seem to be changing not randomly, but rather go in periods:
I can try for half an hour and receive the first, "wrong" result, and
then something changes somewhere, and for another hour I get the
second, "right" result.
Now, is there something obvious, what I don't see?
The sample program goes here:
#define THRNUM 10
printf("Thread 0x%2.2x: %d\n",i,counters[i]);
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message