Re: is it possible to switch between threads manually.
werasm wrote:
On Oct 2, 10:16 am, James Kanze <james.ka...@gmail.com> wrote:
Except that they weren't always called threads:-).
Yes, I'm aware of this. I did maintenance on a Multibus 2 platform
using Intels iRMX in '97. After that we moved to VxWorks. In both
cases they were called tasks.
I've heard that word as well; back in the 1970's and 1980's, I
tended to make the distinction: process ("processus" in French)
when there was no memory protection, task ("t=E2che" in French)
when there was. The real-time embedded processors I mostly
worked on had processes; IBM mainframes had tasks.
This distinction went out the window when I started working on
Unix (late 1980's), which had "processes", but used memory
protection.
(And an incorrectly managed pointer could corrupt the OS data
structures---gave a whole new dimension to undefined
behavior, which really could wipe out a hard disk.)
Yes, cost an inexperienced programmer many late nights. The
biggest culprit being sprintf most of the time.
Or strcpy( malloc( strlen( s ) ), s ). On big-endian machines,
that got the allocator writing to low memory very quickly.
[...]
(Without preemption, you don't need locks, because your thread
will retain control of the CPU until you tell the system it can
change threads.
... After which the system would preempt you and give control
to the other thread?...;-)
If you request/authorize the switch, is preemption the correct
word? (My "feeling" for the word preempt is that it implies
something happening without my particularly desiring it.)
It's actually a much easier model to deal with,
but of course, it makes no sense in a multi-CPU environment.)
I've never used or heard of this model before (non-preemptive).
I'm not aware of anyone implementing it under processes. It
obviously requires co-operating processes/threads, and so isn't
appropriate for processes on a general purpose, multi-user
system. Threads within a process are supposed to collaborate,
however, and I think that in most cases, it would be preferable
to the preemptive model we find every where.
I could perhaps think of simulating it, but that would require
locks.
I've considered that once or twice as well. A single mutex
lock, always held except when you wanted to allow a context
switch (instead of only holding it when you didn't want to allow
one). It makes a lot of things considerably easier, but it does
require wrapping all system calls that might block, to ensure
that they count as legitimate context switch locations. (My
main consideration was to allow lock free logging---logging, of
course, uses common resources which need protection.)
I've implemented something like a ADA rendezvous (if I understand
it correctly) that waits for another thread to complete an operation
that specified by it. This seems to simulate this model as the thread
literally preempts when it goes into the Rendezvous, but it certainly
requires locks.
Do you have examples (of non-preemptive sched) for interest sake?
Nothing recent, but we used it a lot on the 8080. (The
non-preemptive kernel I used on the 8080 fit in less than 80
bytes. Very useful when you only had 2K ROM for the entire
program.) I think that early Windows (pre-Windows 95) also used
non-preemptive scheduling for its processes, but I'm not really
sure; I never actually programmed on the system---I just heard
rumors that non-cooperating processes could hang the system.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34