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.
"Mark K. Gardner" <mkg@xxxxxxxxxxxxxxx> writes: > David Rush <kumo@xxxxxxxxxxxxx> writes: > > Another case where this kind of thing arises is in the > > implementation of priority inheritance mutexes. In this case each > > mutex has an associated priority > I'm not sure I followed you. First of all, if the mutex isn't assigned > the highest priority of any task that acquires it, the potential for > priority inversion (a low priority task executes while a higher > priority task is blocked) is still there. Guilty. I forgot this requirement and opnly remembered it when I was working out precisely *why* I had a hard time implementing them later. > Second of all, a correct > implementation of priority inheritence raises the temporary priority > of the task holding the mutex each time a higher priority task > attempts to acquire the mutex. As soon as it releases the mutex, the > task's priority returns to the priority it had before it acquired the > mutex. Since a task can hold several mutexes, this requires a stack of > (increasing) priorities, with the priority at the bottom of the stack > being the task's original priority. This doesn't seem quite right, but I expect that you know better than I. It seems like you need a priority stack per task/mutex? But that's not particularly germane to SRFI-18. > I see nothing in the integer > implementation that would prevent the use of integer priorities. In > fact, priority inheritence is routinely done in fixed priority RT > systems. Integer priority was *not* the difficulty. The difficulty was avoiding a race condition on mutex release while trying to restore the original thread priority. The result of the race was a incorrect restored priority. If I'm totally confused, please excuse me, this *was* over a year ago. The point of my examples was to show the usefulness of WITHOUT-SCHEDULING in implementing complex priority management schemes. > I believe Marc's objection to parameterizing the scheduler with > THREAD-PRIORITY>? (or allowing modular schedulers) Aren't these two very different problems? THREAD-PRIORITY>? would be a small subset of a modular scheduler. The idea is that the > comparison is in there anyway, why not expose it? Then we get a number of benefits to the specification (e.g. no need to say anything more about priority). > is that it is very > difficult to design the rest of the thread/mutex/condition variable > system abstractly enough to allow things to work without heavy > penalties in performance. (Depending on your definitions of > "difficult" and "performance", the design may be impossible.) I have no way to judge. I'm just (at the moment) a whingeing user. Whichever way Marc goes with this, we'll be ahead of where we are now. > Furthermore, the properties of the system depend critically upon the > parameterizing comparison function hence it makes the use of > independently developed libraries which use threads problematic. Their > semantics will change depending on the comparision function you > install. Which I think is the point of having the scheduler parametric on the priority comparison function. The SRFI can guarantee properties based on the standard THREAD-PRIORITY>? but you're on yer own if you implement yer own. Additionally, follow-on SRFIs could just standardize THREAD-PRIORITY>? to get a new standardized thread system behavior. david rush -- I repeat myself when under stress. I repeat myself when under stress. I repeat myself when under stress. I repeat myself when under stress. I repeat myself when under stress. I repeat myself when under stress. I repeat myself when under stress. I repeat