Hi Eliot, that's nice to know the strict definition of "preempt" vs.
yield -- I think I loosely equated them in my mind before as just a
process switch; still paying attention to the rules, and was the
context I was responding to Tim in.

Yes, I remember the new processPreemptionYields preference and its new
default value which switched the behavior from sending prempted
processes to the back of the queue, to now putting them onto the front
of the queue, permitting cooperative multi-threading OOTB.  I still
don't know if I could bring myself to employ such subtlety...  I like
the explicitness and safety of explicit control (via Semaphores,
Mutexes, etc.), but its nice to know if I *could* use coop which might
even perform better by not push/popping all those extra blocks..



On Mon, Feb 27, 2017 at 2:30 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> Hi Chris,
>
>    forgive my pedantry, but this is important.
>
> On Mon, Feb 27, 2017 at 11:35 AM, Chris Muller <asqueaker at gmail.com> wrote:
>>
>> >> >> A single process to write and another to read, both at same priority
>> >> >> so only one can be  doing stuff at once.
>> >> >
>> >> > Mmmm, those two will not preempt each other - but other processes
>> >> > with
>> >> > higher prio preempt them (right?), so perhaps I am daft but doesn't
>> >> > that
>> >> > mean they will switch anyway (potentially in the middle of a method
>> >> > etc)?
>>
>> In essence, they do preempt each other.  They will not preempt each
>> other when they are blasting bytes over the network, but as soon as
>> the net buffer fills up due to waiting for data transmission in either
>> the send or the receive, the other one, if data is available, will
>> take off.
>
>
> No they will *not* preempt each other.  Preemption means an arbitrary
> suspension of the preempted thread by another thread.  It does /not/ mean a
> thread blocking and hence yielding to another thread.  So what will happen
> with the two threads reading and writing sockets is that they will only
> suspend when they wait on some semaphore that is to be signalled when some
> activity (e.g. reading or writing) is complete.  And these suspension points
> are (if properly written) safe points.
>
> So to the question: "doesn't that mean they will switch anyway (potentially
> in the middle of a method etc)?"
>
> With the standard Smalltalk-80 scheduler, yes.  Any preemption by a higher
> priority process put the preempted process to the back of its run queue,
> hence causing the next process at that priority to also preempt the
> preempted process.  This destroys cooperative multi-threading.
>
> But the current Cog scheduler does /not/ put a process to the back of its
> run queue provided it is in the right mode (see SmalltalkImage current
> processPreemptionYields = false  and ProcessorScheduler class>>#startUp: as
> mentioned elsewhere). In this mode the lower-priority process gets preempted
> by the higher-priority process, but remains at the head of the run queue at
> its priority and so as soon as the higher priority process blocks the lower
> priority process will resume where it left off.
>
> So the new scheduler mode (a mode that's been in the VisualWorks scheduler
> by default for many decades) preserves cooperative scheduling amongst
> processes of the same priority.  It /does/ prevent processes at the same
> priority from preempting each other.
>
> Hope this clarifies things.
> _,,,^..^,,,_
> best, Eliot
>
>
>