This page is part of the web mail archives of SRFI 18 from before July 7th, 2015. The new archives for SRFI 18 contain all messages, not just those from before July 7th, 2015.
Marc Feeley <feeley@xxxxxxxxxxxxxxxx> writes: > > Caveat lector: yadda yadda... > The latest revision of SRFI-18 says: > Each thread has a "priority", which is an exact integer (where higher > numerical values mean higher priority) ... > is this not clear? It is clear. I was skimming, and other verbage led me to think it worked the other way. No, I don't remember which bit, I'll check again and let you know if it was more than just a brain fart. > > Which was Marc's main complaint about the THREAD-PRIORITY>? > > primitive. But the fundamental problem is that whenever you have a > > change in the priority levels of the tasks in a system the scheduler > > has to stop and get its head screwed back on straight. > > Yes, but this is much easier to implement if the scheduler has a > builtin semantics for priority. called (for lack of a better term) THREAD-PRIORITY>? :) Ultimately it's going to boil down to a call to > in your code, right? Which in an arbitrary Scheme might not even be atomic (due to unboxing, etc. although this is something of a strawman). In some ways you have *more* control over the semantics of THREAD-PRIORITY>? because you can specify its constraints in the SRFI specification. > > Which leads me to wonder if some form like > > (without-scheduling <thunk>) ... > This is not sufficient, because the actual exception handler you need > depends on context. In my example I was assuming that the exception > handler exits the with-exception-handler, but this is not guaranteed > since exception handlers can return (which is a good thing in > general). Fair enough. I blindly took your implementation as exemplary, not as definitive. Nevertheless, it is very useful to be able to turn the scheduler off, particularly for an RT system. Now hard-core RT people won't be afraid to hack your implementation to bits to get the behavior they want, so in a certain sense it doesn't matter. But I gave you an example where the ability to turn the scheduler off temporarily simplifies implementing priority-management algorithms without hacking the scheduler code directly. The ability seems likely to be advantageous in any priority-management algorithm, I just haven't implemented that many. > In my opinion, disabling scheduling with (without-scheduling <thunk>) > or any other mechanism is not an option because the runtime system may > depend critically on the thread system Of course. But we're not talking about unbounded time in the WITHOUT-SCHEDULING block. Now if someone *does* such a foolish thing they get what they deserve, but it *is* useful to have some way that users can interact with the *scheduler's* critical section (reordering the priority tree) without having the rug yanked out from under them. When I built the priority-inheritance mutexes on top of pSOS, we (I had four people doing line-by-line reviews and simulations of my code) ended up needing a system-wide lock just to make sure that we didn't get the priorities wrong during mutex release. After consulting with a pSOS expert, he suggested that we bring the code inside the kernel so that we would be effectively running with the scheduler blocked. The need to temporarily stop the scheduler occurs. Doing so can have significant consequences, but it would be a good thing to export that ability to userland. > Fundamentally, thread-priority>? needs to be a lower-level procedure > that lives by different rules. It should not be at the Scheme > level. Something makes me think that we are talking at cross-purposes here. All that matters is that the rules for THREAD-PRIORITY>? be documented. If the constraints for writing THREAD-PRIORITY>? can't be satisfied in Scheme, then there's something wrong with Scheme that should be addressed. I really don't get your objection here, people do this sort of thing in C all the time. > > There is nothing in Marc's objections which doesn't apply in > > the C world *and* which doesn't also apply to an attempt to map > > everything onto integer priorities. The only exception is not being > > able to make a procedure call, which seems a harsh restriction, and > > one that you wouldn't encounter in a C based solution. > > I'm not sure how much interesting work you'll be able to do without > procedure call! I can certainly tail-recursively look at global data structures and other things to find out who *really* has the highest priority. Can we make a distinction between primitive language operations and procedures? Is it reasonable to expect + to be implemented atomically? If so, then I can probably do some basic arithmetic and comparisons. If not, you might well not be able to implement your thread system at all. Remember, we're not talking about serious amounts of work here; we're talking about figuring out if one process should run preferentially to another one. And finally, pushing THREAD-PRIORITY>? out to userland enables you to punt on the open issue of priority aging in SRFI-18. All you need do is document the constraints under which THREAD-PRIORITY>? must be implemented. david rush -- As I've gained more experience with Perl it strikes me that it resembles Lisp in many ways, albeit Lisp as channeled by an awk script on acid. -- Tim Moore (on comp.lang.lisp)