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
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, Bulat mailto:Bulat.Ziganshin@gmail.com
On Saturday 01 April 2006 16:26, Bulat Ziganshin wrote:
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?
I think you cannot, at least not without implementing your own (priority based) scheduler ;) Thread priorities are seldom needed, but /if/ you need them, there is really no practical way around them. My standard example is motion control. You have a thread for the low-level feedback loop, and one or more threads for high-level motion planning. The latter is usually a lot more CPU-intensive, but the former needs to run whenever enough data is available (usually from some position or velocity readback device). For such applications, priority based (preemptive) scheduling is the only practical solution I know of. I would argue that /some/ support for thread priorities should be in the standard, maybe as an extension. Ben
participants (3)
-
Benjamin Franksen -
Bulat Ziganshin -
Simon Marlow