Re: Multitasking vs. multithreading
-----Original Message-----
From: Kevin Sieger <simkin at ZEBRA.NET>
To: Multiple recipients of list EUPHORIA <EUPHORIA at MIAMIU.ACS.MUOHIO.EDU>
Date: Wednesday, March 04, 1998 6:09 PM
Subject: Re: Multitasking vs. multithreading
>MAP wrote:
>
>> Kevin Sieger wrote:
>> >
>> > Seems I am having trouble here...I've got some code for multitasking=
in
>> > the Pascal environment, and I'm thinking of implementing this simple
>> > multitasking in a game I am developing. I remember months back
>> > searching Dejanews that someone had suggested multithreading for a
>> > multiuser game. After many searches on inet, I've been unable to fi=
nd
>> > any decent multithreading examples. Just what is the difference
between
>> > multitasking and multithreading. And, I do believe the tasking is
>> > easily done in Euphoria, but what about the threading?
>> >
>> > Thanks!!
>> > Kevin
>>
>> I'm no expert on this, as yet I've never written anything using
>> multithreading. My understanding of the difference between the two
>> is this; multitasking simply refers to running two seperate programs
>> concurrently, multithreading is used to run two processes within the
>> same program concurrently. Multithreading simply isn't possible under
>> Dos. I think I remember reading the old doshell program "emulated"
>> multitasking of programs ran in it, but by some definition it was
>> regarded as not being "true" multitasking.
>> The win95 system offers both. Multitasking takes place all the time as
>> you run two programs at the same time. Multithreading is set up throug=
h
>> calls to the kernel32.dll interface. I also understand it to be that
>> multithreading does not increase the speed of your programs unless
>> you are running on a multi-processor machine (might actually be slower=
).
>> It just makes the program capable of carrying on other processes while
>> still interacting with the user.
>>
>> Christopher D. Hickman
>
> Hmm, it seems there is a term conflict here, not necessarily yours. T=
he
>units which I have implement a simple multitasking within a pascal progr=
am,
>i.e. instead of one or more programs running concurrently, it will allow
>different procedures, functions etc. assigned as tasks, to run inside of
the
>same program. The unit is non-preemtive (OS/2, Linux, and WinNT being
>preemptive), but is more of a ccoperative multitasking. It is hard to
>explain, but according to your definition, this would be multiTHREADING.
>Anyways, I believe this unit to be easily coded into Euphoria.
>
>BTW, the unit is for TP6+, so the target system would be DOS.
>
>Thanks!!
>Kevin
Here is an clip from the Win95 resource kit I think that it will clearup =
the
difference between MultiTasking and MultiThreading. Seek out the resourc=
e
kit for more info on this subject.
---------------------- Begin
Clip --------------------------------------------
The Process Scheduler is the component responsible for providing system
resources to the applications and other processes you run, and for
scheduling processes to allow multiple applications to run concurrently.
The Process Scheduler also schedules processes in a way that allows multi=
ple
applications and other processes to run concurrently. Windows 95 uses two
methods for concurrent process scheduling =97 cooperative multitasking an=
d
preemptive multitasking.
With Windows 3.1, applications ran concurrently through a method known as
cooperative multitasking. Using this method, the operating system require=
d
an application to check the message queue periodically and to relinquish
control of the system to other running applications. Applications that di=
d
not check the message queue frequently would effectively =93hog=94 CPU ti=
me and
prevent the user from switching to another application. For compatibility
reasons, Windows 95 cooperatively multitasks Win16-based applications.
Windows 95 uses preemptive multitasking for Win32-based applications. Thi=
s
means that the operating system takes control away from or gives control =
to
another running task, depending on the needs of the system.
Unlike Win16-based applications, Win32-based applications do not need to
yield to other running tasks to multitask properly. Win32-based applicati=
ons
can take advantage of multithreading, a mechanism that Windows 95 provide=
s
to facilitate the ability to run applications concurrently. A Win32-based
application running in the system is called a process in terms of the
operating system. Each process consists of at least a single thread of
execution that identifies the code path flow as it is run by the operatin=
g
system. A thread is a unit of code that can get a time slice from the
operating system to run concurrently with other units of code, and must b=
e
associated with a process. However, a Win32-based application can initiat=
e
multiple threads for a given process to enhance the application for the u=
ser
by improving throughput, enhancing responsiveness, and aiding background
processing. Because of the preemptive multitasking nature of Windows 95,
threads of execution allow code to be smoothly processed in the backgroun=
d.
A good illustration of this is the Windows 95 shell itself. Although the
shell is a Win32-based process, each folder window that opens is a separa=
te
thread of execution. As a result, when you initiate a copy operation betw=
een
two shell folder windows, the operation is performed on the thread of the
target window. You can still use the other windows in the shell without
interruption, or you can start a different copy in another window.
In another example, a word processing application (a process) can impleme=
nt
multiple threads to enhance operation and simplify interaction with the
user. The application can have a separate thread that responds to keys ty=
ped
on the keyboard by the user to place characters in a document, while anot=
her
thread performs back-ground operations such as spelling checking or
paginating, and while a third thread spools a document to the printer in =
the
background.
Note Some Win16-based applications may have provided functionality simil=
ar
to this; however, because Windows 3.1 didn=92t provide a mechanism for
supporting multithreaded applications, it was up to application vendors t=
o
implement their own threading schemes. The use of threads in Windows 95
makes it easy for application vendors to add asynchronous processing of
information to their applications.
---------------- End Clip ------------------------------------------
|
Not Categorized, Please Help
|
|
