Re: forget coorporative multitasking in .NET ?

From: Cor Ligthert (notmyfirstname_at_planet.nl)
Date: 01/02/05 

Date: Sun, 2 Jan 2005 17:30:53 +0100

Frans,

Thanks, reading this my mind did say everytime of course.

So it added to my knowledge that it was restoring from the back to the
front.
(Although there are as well new elements)

For me was IBM the first who came with that "MultiTasking" term and JCL is
Job Control Language.
http://www.okstate.edu/cis_info/cis_manual/jcl_toc.html

As far as I remember me, where there 2 terms in past, multiprogramming what
was doing more programs, processes, threads on one system. Multiprocessing
could not be used because that was doing one process on more processors.

However than came IBM with "multitasking", probably with the same reasons as
you tell it about how the words where used in the ms-Dow/Wind311
environment.

And in the oposite maybe from you about 25-30 years ago I made a system with
a seperated database layer, securitylayer, business layer and datacom (ui)
layer with threads who where working side by side using queues, and all was
done none parallel and therefore securing a high throughput.

However when I had directly searched on Google I could have found a lot of
answers, from what I don't say that your answer did not give something
extra.

http://en.wikipedia.org/wiki/Computer_multitasking#Multiprogramming

Thanks again for your explanation.

Cor
.
"Frans Bouma [C# MVP]" <perseus.usenetNOSPAM@xs4all.nl>

> Cor Ligthert wrote:
>> Willy,
>>
>> This makes me curious, I know the term multitasking as an IBM term, what
>> was a substitute of multiprogramming a term used by Burroughs.
>> Multiprogramming did mean that you did not have to keep track on the
>> programs that where executed, they where managed by the OS side by side.
>> Although you could (as far as I remember me) set with multiprogramming
>> priorities about scheduling, executing and virtual memory, while there
>> where a lot of possibilities of queuing and to synchronize the programs
>> that used those what you can call using programs as threads.
>>
>> Mutlitasking was something (it was in the seventies) you had to set by
>> hand (JCL) in those days. However there was an advantage from
>> multitasking, with multitasking you had to tell what part of memory would
>> be used and therefore the memory was protected. What was impossible with
>> a Burroughs system (although I have never seen an error with that and was
>> coding in BPL (a PL1 substitude) and Cobol for that computer). IBM has
>> forever had a good marketing team, so you know probably how important
>> that memory protection became.
>>
>> For those days a Burroughs system was great, however probably much too
>> advanced for those days.
>>
>> In a Burroughs system was everytime the program pushed down, when there
>> was a new one loaded.
>>
>> Therefore I compare that Burroughs system often with W9x while as we know
>> NTx comes from that IBM OS although it is not anymore done by hand (JCL).
>>
>> Can you maybe give me some light if my comparing is wrong in this,
>> because I was a long time not interested in computer OS architecture
>> however want to know where I am wrong in my ideas?
>
> I don't know what IBM nor JCL (?) has to do with it, but the thing is
> this:
> on 16 bit windows (win3.xx), the scheduler worked with 16bit processes
> only and basicly scheduled the processes/threads once the thread who had
> the processor gave execution back to the scheduler. This is called
> 'co-operative' as multi-tasking was depending on the cooperation between
> applications. I.e.: if an application didn't give execution back to the
> scheduler, the system 'hanged' (no other threads got the CPU) unless a
> non-maskable interrupt was triggered.
>
> on 32bit windows based on the win95 kernel (win9x, winME) the scheduler
> worked pre-emptively. This means that the whole system was divided in
> 32bit processes and the scheduler scheduled the threads of these processes
> using a priority stack and some other protocols (mostly round-robin). Each
> thread in the system was given a fixed amount of time, after that, the
> scheduler simply took teh CPU away from the thread and the thread was
> physically halted as another thread was given the CPU. It depended on the
> priority/place in teh thread queue which thread was given the CPU. This is
> totally different from the 16bit OS, as the scheduler decided which thread
> was given the CPU, not the thread currently running.
>
> 16bit applications were all ran in a single 32bit process. 16bit processes
> on 16bit windows shared the system memory so they all had access to
> eachother memory and as they were all scheduled as 1 process, their
> multitasking was still depending on co-operation, as the whole 16bit
> process space was given the CPU, inside it it was then decided which
> process got the CPU, i.e.: the last process which had the CPU.
>
> On 32bit windows based on the NT kernel, this is not that different,
> except from teh fact that 16bit processes are run inside a virtual
> machine.
>
> Co-operative multi-tasking is stupid. It easily hangs the machine.
> (win9x/ME also had problems with 16bit processes which stepped on its own
> 16bit OS libraries (as they all shared the same memory), for example parts
> of the shell were 16bit code, so a bad 16bit program could hang the
> complete system, as it could overwrite parts of the OS without having the
> OS stopping it because of a GPF)
>
> Co-operative multi-tasking is also just a trick to do things 'in parallel'
> without having to work with threads. The reason why some people still want
> it is that they want to do things in parallel in a synchronious way, as in
> pre-emptive multi-tasking it is undefined which thread gets the cpu and
> when, so it requires extra code to make asynchronous code work as planned
> and debugging that kind of code can be cumbersome.
>
> We all do have synchronous multitasking code today: simply write a routine
> and call from that routine your other routines. That's co-operative
> multitasking. As I wrote earlier, a state-machine can help you with this.
> You can chop up a long running routine into several states and hop between
> them using the state machine, which then allows you to add states in
> between these 'substates' to get things done in parallel, but in a
> synchronous way. Using this I wrote 13 years ago a parallel computing
> system for a 120-node sparc cluster (in C) which could schedule and
> dispatch jobs on all the nodes, synchronously and in parallel without
> having to have a lot of threads and syncing code in place.
>
> Frans.
>
> --
> ------------------------------------------------------------------------
> Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
> My .NET blog: http://weblogs.asp.net/fbouma
> Microsoft MVP (C#)
> ------------------------------------------------------------------------

Relevant Pages

  • Re: forget coorporative multitasking in .NET ?
    ... > This makes me curious, I know the term multitasking as an IBM term, what was ... > multitasking you had to tell what part of memory would be used and therefore ... the processor gave execution back to the scheduler. ... time, after that, the scheduler simply took teh CPU away from the thread ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: [Lse-tech] [PATCH] cpusets - big numa cpu and memory placement
    ... > Ooooh, CPU 3 over there looks heavily loaded, I'll steal something. ... memory allocated that hurt on our big boxes - such as blowing out one ... The kernel allocator and numa placement policies don't really integrate ... have scheduler and allocation policies handled on a "per-domain" basis, ...
    (Linux-Kernel)
  • Re: Which dual opteron?
    ... >> different memory areas. ... >> (the scheduler should prefer one CPU when only one process is ready), ... >enable NUMA or not in the kernel config? ...
    (comp.os.linux.hardware)
  • One minute delay when booting 2.6.24.1
    ... Switched to high resolution mode on CPU 1 ... io scheduler anticipatory registered ... # Infrared-port device drivers ...
    (Linux-Kernel)
  • [RFC][PATCH] O(1) Entitlement Based Scheduler
    ... This patch is a modification of the Oscheduler that introduces ... _entitlement_ to CPU resources that is determined by the number of _shares_ ... This patch provides both soft and hard CPU usage rate caps per ... one getting the most can be given a better priority, ...
    (Linux-Kernel)