>Binding threads to LWPs... Don't.
>Yes you CAN, but it's not what you want to do. 99.9% of the people who
>think they need that are wrong. (Yes, I understand that you are that 0.1%,
>but that's what all the other guys say too.)
>Before you commit this mistake, look VERY VERY hard at the problem, ask a
>peer to review it. Tell 'em some guy at Sun said "don't". And if you still
>want to do it... tell me how it went. I'll be interested to know
I'll agree that 99.9% of the time they are wrong. We other decimal places
*do* have a use for it.
In applications involving overlapped I/O (aka async, but that is somewhat
overloaded these days) using threads, it is occasionally necessary.
An example (all too sadly from real life :-)
An application does I/O to a driver that is not modifiable, and that does
not sort the requests by offset. In other words, the requests must be
presented in the proper order.
As thread priority is LWP acquisition priority, *NOT* scheduling priority,
RT threads are required in order to do deterministic scheduling. Before
request N+1 can be issued, request N must run and block on the I/O request
before the thread generating request N+1 can issue the I/O.
The thread(s) doing I/O therefore run at higher priority than the thread
generating the requests. Only RT will do this correctly, and to do that
you need THR_BOUND, as the priorities are done with the LWP.
In the 99.9% case, you either have a driver that does the Right Thing
and sorts, so weakly ordered I/O is not a problem, or the order of
the requests does not matter.
Bottom line - if you require deterministic scheduling, and many RT
applications do, you have to use a bound thread. Now if I could only
*them too :-)
l & h,
Uniq Professional Services Pty Ltd ACN 056 279 335 | Why Not?
PO Box 70, Paddington, NSW 2021, (Sydney) Australia |
Phone: +61-2-360-7434 Fax: +61-2-331-2572 |