Re[4]: thread priorities?
Hello Simon, Friday, March 31, 2006, 4:57:19 PM, you wrote: threadSetPriority :: ThreadID - Int - IO () 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. Yes, but the Erlang implementation doesn't do anything about priority inversion. Also, I don't think Joel really wanted priorities, his problem could have been solved by using bounded channels. to be exact, his problem (1000 producers and one consumer) can be solved ONLY by using some bounded queue. but for typical usage when there are one or several producers and one consumer, priorities allow to solve problem: 1) in easier and more intuitive way, that is well known from other environments (Unix, for example) 2) without introducing new data structures - bounded channels, bounded priority queues and so on, so on (although it should be easy to construct them) priorities are also useful for solving other problems, where bounded queues can't help us. as i said, my own program contains one thread that reads thousands of files from disk and pushes their data into the queue. then other threads process these data. as you can see, first thread is I/O-bound while other is CPU-bound. of course, i want to give higher priority to the first thread so that it reads next portion of data as soon as previous read operation is complete (and there is free buffer). how can i accomplish it with current ghc implementation? -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: thread priorities?
Simon Marlow [EMAIL PROTECTED] writes: 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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
RE: Re[2]: thread priorities?
On 31 March 2006 10:24, Bulat Ziganshin wrote: 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. Yes, but the Erlang implementation doesn't do anything about priority inversion. Also, I don't think Joel really wanted priorities, his problem could have been solved by using bounded channels. Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
thread priorities?
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 = ... with a small modification to the progress guarentee saying that when threads of different priorities are runnable, one of the threads of the highest priority will be running. we should also say something about priority inheritance via MVars... but perhaps this is too complicated for the spec and should be left up to the implementations (or just make it always advisory). let me know what y'all think. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
