"Smalltalk" and "Real-time"

Volker Zink wrote:
> VisualWorks is missing preemption.

This is _false_.  VisualWorks (and all Smalltalk-80 compliant
schedulers) provide preemption across priorities; i,e, a higher priority
process preempts any lower-priority process.  But within a priority
scheduling is preemptive.

A bug in the original Smalltalk-80 scheduler (described in the blue
book) is that if a process is preempted it gets added to the back of its
run queue, so in the original Smalltalk-80 a runnable process that gets
preempted by a higher priority process will in effect yield to all
runnable processes at that priority.  This is fixed in VisualWorks so
preempting a process no longer forces it to yield.

One can implement a time-slicing scheduler within VisualWorks (if one
wants it) by having a high priority process loop waiting on a delay the
length of the time-slice.  Once past the delay the process moves the
active timesliced process to the end of its run queue, making that
process yield.  One can usefully implement such a scheduler to operate
only on a pool of processes (e.g. those in some server worker pool).

One thing that VisualWorks *does* lack is fair semaphores.  Currently
Semaphore>>signal on a non-empty semaphore makes runnable the first
highest-priority process, _not_ the first process running on the
Semaphore.  I'm told that for some applications this is a serious flaw
and one that's been on the to-do list for too long :/

 > But this is not really important. You
> can easily write something yourself. At least i wrote a ProcessManager
> for my scheduled tasks (each tasks runs in an own process) which just
> waits some time and then yields the active task.

Right.

[snip]

>
> A more complete infrastructure for processes in VisualWorks would be
> nice though (especially i would like interprocess-exceptions but luckily
> i found an article on "Cross-process exception handling" by Ken Auer and
> Barry Oglesby in an old Smalltalk Report).

Quite.  It can be implemented given the current infrastructure.


--
_______________,,,^..^,,,____________________________
Eliot Miranda              Smalltalk - Scene not herd

Eliot Miranda <[hidden email]> wrote in
news:nVJ%d.71$[hidden email]:

>
>
> Volker Zink wrote:
>> VisualWorks is missing preemption.
>
> This is _false_.  VisualWorks (and all Smalltalk-80 compliant
> schedulers) provide preemption across priorities; i,e, a higher
> priority process preempts any lower-priority process.  But within a
> priority scheduling is preemptive.

I think you meant to write that "within a priority scheduling
is non-preemptive", i.e. when a process becomes ready to run
it does not preempt a process of the same priority.

Eliot Miranda schrieb:
In the strict meaning of the term 'preempting' - and that is the term
used in the discussion here so far - you are right.

        "The act of taking control of the operating system from
        one task and giving it to another task is called preempting."
        [quoted from whatis.com]

This is what happens in VW because lower priority processes are
preempted in favor of higher priority processes.

But as far as the term is used nowadays 'preemptive multitasking' also
means that there is a process scheduler which also handles processes
with the same priority.

        "In preemptive multitasking, the operating system parcels
        out CPU time slices to each program."
        [quoted from webopedia]

        "In simple terms: Pre-emptive multitasking involves the
        use of a scheduler which hands out CPU time to various
        process so that they can be performed simultaneously.
        Therefore all processes will get some amount of CPU time
        at any given time."
        [quoted from Wikipedia]

And this is _not_ the case in VW. So in this wider meaning VW does not
do preemptive multitasking. But i don't want to define preemptive
multitasking/preemption here because i don't really care about terms.

Fact is there is no scheduling for processes with the same priority. No
time slices or whatever. You can quite easily implement it yourself, and
if you do server programming you probably want to do it yourself because
you have your own requirements. Nevertheless some scheduling in core VW
would be nice (maybe different scheduling algorithms so you can decide
which to use and with the possibility to plug-in your own).

As i stated in previous posts i believe that when multicore processors
gets mainstream there should be support for them in VW and this would be
a good time to do some work on the process framework.

Volker

Volker Zink wrote:

In a strict technical sense, both the topic
and the above reply are strictly technical,
not to mention true and correct.


> But as far as the term is used nowadays 'preemptive multitasking' also
> means that there is a process scheduler which also handles processes
> with the same priority.


Well, some people apparently do this, but should a mistaken
understanding (i.e. falsehood) suddenly transmute into 'new meaning'
(i.e. truth) simply by way of increased occurrence?

A better path, it seems to me, is to assist in increasing
the frequency of informed use of the terminology, especially
when 'strict technical' differences in behavior are involved.


>
>     "In preemptive multitasking, the operating system parcels
>     out CPU time slices to each program."
>     [quoted from webopedia]


The above is an erroneous definition, despite
the fact that it is being provided by a computer,
or that the source has a presence - AND a registered
address on the information super highway, or that the
quoted source has the characters 'pedia' right in the
name.


>     "In simple terms: Pre-emptive multitasking involves the
>     use of a scheduler which hands out CPU time to various
>     process so that they can be performed simultaneously.
>     Therefore all processes will get some amount of CPU time
>     at any given time."
>     [quoted from Wikipedia]


In simple terms, the above is overly simple, and the result
is an erroneous statement.

"As simple as possible, but no simpler".


> And this is _not_ the case in VW.


Absolutely true.

Now - how shall we utilize this fact?


> So in this wider meaning VW does not do preemptive multitasking.


Not such a good choice, here.  But only because
there are better choices at our disposal.


> But i don't want to define preemptive multitasking/preemption here
> because i don't really care about terms.


There are better choices here too.

(Also, the preceding use of multiple citations
  to external "authority" is prima facie evidence
  of the converse.
)

Here is an alternate citation:

---
Pre-emptive multitasking
 From Wikipedia, the free encyclopedia.

Pre-emptive multitasking is a form of multitasking. To understand the
concept, compare to cooperative multiprocessing, in which only the
active task (a.k.a. process) may initiate a context switch:

     * Because the task has completed processing.
     * Because the task has become blocked on a shared resource.
     * Because the task is yielding the processor to another, similarly
cooperative, task.

In pre-emptive multitasking, the Operating System kernel can also
initiate a context switch to satisfy the scheduling policy's priority
constraint, thus pre-empting the active task.

Usage: Pre-emptive multitasking is sometimes mistakenly used when the
intended meaning is more specific, referring instead to the class of
scheduling policies known as time-shared scheduling, or time-sharing.

---


> Fact is there is no scheduling for processes with the same priority.

One could get *really* pedantic and refute this by noting
that processes are ALWAYS 'scheduled' - the question is
what policy is used to effect the schedule in the case at hand?

But I won't, because I know that you mean that VW
does not provide a 'time-shared' scheduling policy.


> No time slices or whatever.


Yes.


> You can quite easily implement it yourself,


This is a strong statement, and if true,
a powerful result, assuming there is EVER
a context in which ANY benefit can be had
from another scheduling policy.

Thankfully, your statement IS true,
and it IS the case that there are contexts
in which benefit can be had from another
scheduling policy.


> and if you do server programming


I do.


> you probably want to do it yourself because
> you have your own requirements.


I suggest that the word "probably" is a misleading qualifier,
as I believe that, for server programming in particular,
one is more likely to benefit from the absence of a "time-shared"
scheduling policy.

At least, that is the statistical result of my own experience.


> Nevertheless some scheduling in core VW
> would be nice (maybe different scheduling algorithms so you can decide
> which to use and with the possibility to plug-in your own).


Ok - as a request, this is quite reasonable.
Because, (although as you yourself point out, above,
            one can easily implement a "time-shared"
            scheduling policy
          )

there are vendor differences which require
different implementations, even though each one is
short, "simple", and easily understood in each case
(once the rationale and particulars are described).


> As i stated in previous posts i believe that when multicore processors
> gets mainstream there should be support for them in VW


Probably true, and also quite likely to be supported.


> and this would be a good time to do some work on the process framework.


And / or perhaps each vendor could call a bit more
attention to these details, perhaps earlier in the
documentation.


Regards,

-cstb