On 31 March 2006 02:49, John Meacham wrote:
Thinking about it some. I think we will need some sort of very basic thread priorities.
honoring these priorities will be _manditory_ for cooperative implementations but advisory for preemptive ones that meet the fairness guarentees. priorities are sometimes needed in cooperative systems to ensure certain things get run, but the fairness guarentees of preemptive systems make them less important. Another reason to make them advisory in preemptive implementations is because they might be using OS level threads and hence not have their own scheduler to tweak priorities in.
I am thinking
threadSetPriority :: ThreadID -> Int -> IO () threadSetPriority = ...
I'd rather not, if we can avoid it. The only rationale I'll offer is that we don't have it in GHC, and people manage to do a lot without priorities. Priorities come with a whole can of worms that I'd rather not deal with. Cheers, Simon
"Simon Marlow"
I'd rather not, if we can avoid it. The only rationale I'll offer is that we don't have it in GHC, and people manage to do a lot without priorities. Priorities come with a whole can of worms that I'd rather not deal with.
Thread priorities are somewhere between important and necessary for hOp/House. I haven't seen them really required elsewhere though. -- I've tried to teach people autodidactism, | ScannedInAvian.com but it seems they always have to learn it for themselves.| Shae Matijs Erisson
Hello Simon, Friday, March 31, 2006, 12:24:23 PM, you wrote:
threadSetPriority :: ThreadID -> Int -> IO ()
I'd rather not, if we can avoid it. The only rationale I'll offer is that we don't have it in GHC, and people manage to do a lot without priorities. Priorities come with a whole can of worms that I'd rather not deal with.
it was requested by Joel Reymont, and he even give us information how that is implemented in Erlang, together with hint to assign higher priorities to consuming threads. I personally also want to had priorities, in order to run my I/O thread anytime when previous I/O operation is completed, in order to raise overall program performance I also don't see principal implementation problems - instead of round-robin selecting of next thread to run, it should be some more complex structure -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Thinking about it some. I think we will need some sort of very basic thread priorities.
I'd rather not, if we can avoid it.
Agreed. If someone wants to provide them as an optional extra, fine. (We had thread priorities In concurrent embedded Gofer, a long time ago. They can certainly be useful when interfacing with hardware, but there are other ways to achieve the same goals.) As Simon says:
Priorities come with a whole can of worms that I'd rather not deal with.
They certainly do. Unintentional priority inversion is the most basic problem, covered early in any course on real-time systems.
threadSetPriority :: ThreadID -> Int -> IO ()
In any case, if priorities were to be introduced, I would not use Ints to represent them. How many priority levels are sufficient? A partial ordering between ThreadIDs would be preferable. Sometimes priorities are genuinely incomparable, so there is no point in forcing a particular ordering. Regards, Malcolm
On Fri, Mar 31, 2006 at 10:30:51AM +0100, Malcolm Wallace wrote:
threadSetPriority :: ThreadID -> Int -> IO ()
In any case, if priorities were to be introduced, I would not use Ints to represent them. How many priority levels are sufficient? A partial ordering between ThreadIDs would be preferable. Sometimes priorities are genuinely incomparable, so there is no point in forcing a particular ordering.
Well, that is just the sort of complication I wanted to avoid by keeping them simple. I did not want to specify a scheduling algorithm in particular. In cooperative systems, it is quite convinient to have some control over which thread is run next, however, preemptive systems might as well ignore them as eventually every thread will get its time. It is not that important to me though. I'll probably implement it as an extension in jhc since it is straightforward, but have no particular attachment to it being in the standard if others don't feel it belongs in there. John -- John Meacham - ⑆repetae.net⑆john⑈
participants (5)
-
Bulat Ziganshin -
John Meacham -
Malcolm Wallace -
Shae Matijs Erisson -
Simon Marlow