🚀 go-pugleaf

"robertwessel2@yahoo.com" <robertwessel2@yahoo.com> writes:
> Of course that's not anything like the way it actually works.  If
> two threads, one high and one low priority, are ready to run, the
> high priority thread will be dispatched, and time slices have
> nothing to do with it.  In the basic case a runnable high priority
> thread will prevent all low priority threads from running, period.
> If two threads of equal priority are both runnable, then, and only
> then, will time slices come into play to switch between those equal
> priority threads.  That being said, many OSs will apply a dynamic
> temporary priority boost to lower priority threads if they've not
> been allowed to run for an extended period of time so that they're
> not starved of CPU time completely.  And there are, of course, more
> complex schedulers that work not just on thread priority, but take
> into account system policies that say things like "guarantee at
> least 15 % of the CPU to job#3."  Those often work by watching the
> run history and adjusting a more traditional priority scheme to meet
> the goals.

dynamic adaptive resource management that i was doing in the 60s as
undergraduate ... used advisory deadlines for dispatching/scheduling
(effectively based on size of quanta and the amount of resources the
task was getting relative to its target resources).

priorities were an aspect of scheduling policy ... default policy was
fair share and default priority mechanism adjusted a tasks relative
portion of fair share (translated into more or less than overall
infrastructure fair share).

evolution of that infrastructure were things like partitioning
resources among departments and then making individual fair share a
portion of the related departments allication ... as opposed to
overall total system resources.

one of the reasons for doing the change ... was to drastically reduce
the pathlength of the then available implementation which was starting
to take 10-15 percent of elapsed time ... and used a priority scheme
more like that outlined above. previous post
http://www.garlic.com/~lynn/2005p.html#21 Multicores

the code that i had done as undergraduate was eventually picked up and
shipped in the cp67 product. Much of the code was then dropped in the
morphing from cp67 to vm370. however it was re-introduced when i did
the resource manager for vm370.
http://www.garlic.com/~lynn/subtopic.html#fairshare

one of the other distinctions of the resource manager was that it was
chosen to be the guinea pig for licensed/priced kernel software.

with the 6/23/69 unbundling announcement (large part motivated by
various litigation activities), there was a switch to start
charging/licensing application softwoare ... although kernel software
still was free.
http://www.garlic.com/~lynn/subtopic.html#unbundle

the resource manager got tapped to be priced/licensed kernel software.
I got the reward to spend time over period of several months with
various business groups working out the changes for pricing for kernel
software. the guidelines established with the resource manager was
that kernel software not directly involved with hardware support (like
device drivers) would still be free ... but other kernel software
could be priced separately.

this caused a problem for the next base kernel release where they were
going to ship SMP support (something else that didn't make the
transition from cp67 to vm370 ... even tho all the invention leading
up to the compare and swap instruction had been done on cp67). I had
includes a bunch of stuff in the resource manager that SMP support
needed. However the pricing policy wa that SMP support had to be free
(aka hardware support) ... so it was a violation of the policy with
you had to buy the resource manager in order for SMP support to work.
Eventually they moved stuff required by SMP support out of the
licensed/priced resource manager into the base (free) kernel.
http://www.garlic.com/~lynn/subtopic.html#smp

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/