Hi Chris,
forgive my pedantry, but this is important.
On Mon, Feb 27, 2017 at 11:35 AM, Chris Muller asqueaker@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