On Mon, 12 Jan 2004 16:07:52 +0000, Tony Morgan
wrote:


The concept of daemons (which is inherent in true multi-threading) is
alien to Windows technologies.

Are they all that different to processes?

In message , Harry Broomhall
writes
The Unix equivalent to a DLL is a 'shared object'.

When your DLLs (often) page into memory-space used formerly by the
calling program (or another DLL), and when completed return its
memory-space to the pool? "Shared object" is a term conceived in the
wake of "OO" methodology - nothing more. And OO is merely the
formalisation of systems/methodologies/technologies that had been
previously been used for several years.

Overlays are rather different animals.

Remember Wordstar when more than 500K of program as well as data would
run in 64K of memory? And of course the well-known (then) De Smet
compiler?
--
Tony Morgan
http://www.camcord.info
http://www.rhylonline.com

In message , Laurence Payne
writes
On Mon, 12 Jan 2004 16:07:52 +0000, Tony Morgan
wrote:


The concept of daemons (which is inherent in true multi-threading) is
alien to Windows technologies.

Are they all that different to processes?

As I keep on saying Laurence - it's all semantics. In Microsoft-speak, a
process is only a process when it is actually running.
--
Tony Morgan
http://www.camcord.info
http://www.rhylonline.com

In message , Jose
Marques writes
On Mon, 12 Jan 2004, Tony Morgan wrote:

With a single CPU ???

The number of CPUs doesn't matter. Multi-tasking is a way of running more
than one program at a time. On a single CPU this is achieved by switching
quickly between multiple programs letting each one run for a little time.

Exactly. Time-slicing (which others AFAIR disputed).

This can be achieved using time-slicing (where the operating system
forcibly takes control of the CPU from the program at set intervals) or
cooperative multi-tasking (where programs cooperate with the operating
system by giving up control of the CPU voluntarily). As you add CPUs you
just multiply the number of programs that can be active at any one time,
that's all. Within a single program you can use multi-threading to
perform more than one task at the same time within that program. Again
multi-threading can be implemented using time-slicing or by using
cooperative multi-tasking.

Multi-tasking *is* time-slicing (unless you have a one-to-one
relationship between the number of threads and number of CPUs).
If you have more than one CPU, and the
operating system supports it, then multiple threads in a single program
can run on multiple CPUs, however, some operating systems are limited to
running all threads belonging to the same program on the same CPU.

Time-slicing again ?

Daemons (which have been the "engines" of multi-threading) in Unix have
been around for a very long time.

A daemon is a just a program that runs in the background and provides
services to other programs.

Exactly. As others here have asserted - processes, program threads etc
depending on the semantics you are adopting.

It has nothing to do with multi-threading
other than you can write your daemon to use multi-threading (though for
simple daemons this may not make much sense).

Err.... One daemon for each thread ?

Anyway, all this is getting completely OT - not only for the OP but for
the newsgroup itself :-)

I had to thread (pun) back to remind myself that the OP was about
drivers for the Voodoo 5 5500 video card :-)

--
Tony Morgan
http://www.camcord.info
http://www.rhylonline.com

Time-slicing again ?

No. Time-slicing is where the OS gives each process a piece of cpu time - this
time is finite. The code stops operating at the end of that time, all registers
are saved and another process takes over. When the stopped process is restarted
it is started from the next instruction pointer after all the registers have
been reloaded.

Threads and interrupts are different. I won't try to explain threads here,
they're not really relevant. Have a look at

http://msdn.microsoft.com/library/de...dn_threads.asp

However, interrupts are important as it would be impossible to capture video
through cpu time-slicing as the cpu could just stop in the midst of a frame
capture.

Interrupts, which is one piece of jargon that is apt, are piece of code length
of operation is determined by the task and usually has to finish before exiting.

They stop the cpu's current task and force the cpu to execute their code. The
main problem with interrupts is that under windows they are often shared with
drivers being daisy chained onto a single interrupt. This means that when an
interrupt event occurs, the OS passes control to the first driver in the chain
who needs to declare ownership or pass it on to the next driver.

The most common cause, as I said before, of seemingly flaky firewire cards is
that they share an interrupt with a sound card, a video card, a network card or
some other card whose driver's code other fails, or takes too long, to pass on
the interrupt to the correct firewire driver. It is, also, the case that cheap
OEM firewire cards sometimes have poor drivers. The driver's interrupt code must
finish before another interrupt occurs. (OK, that is simplistic as it is
possible to write re-entrant code)

Stuart McKears

www.mckears.com

On Mon, 12 Jan 2004 18:29:51 +0000, Tony Morgan
wrote:

The concept of daemons (which is inherent in true multi-threading) is
alien to Windows technologies.

Are they all that different to processes?

As I keep on saying Laurence - it's all semantics. In Microsoft-speak, a
process is only a process when it is actually running.
--

So, the CONCEPT is shared, the name is different? :-)

On Mon, 12 Jan 2004, Tony Morgan wrote:

Multi-tasking *is* time-slicing (unless you have a one-to-one
relationship between the number of threads and number of CPUs).

No. Time-slicing is a way of implementing multi-tasking. Saying that
multi-tasking is time-slicing is the equivalent of saying that houses are
bricks. You can implement multi-tasking without time-slicing. For
example, MacOS 7.x and Windows 3.1 use coroutines to share the CPU.

Exactly. As others here have asserted - processes, program threads etc
depending on the semantics you are adopting.

No. A process and a thread are different things. A process is a CPU state
with it's own address space. A thread is a CPU state that shares its
address space with other threads.

Err.... One daemon for each thread ?

Unix didn't have threads until recently. A daemon is a process, it has
nothing at all to do with threads. It is possible to use threads within a
daemon (eg. the MySQL database uses threads to manage client connections
within a single process) but it is equally possible to not use threads at
all (eg. the PostgreSQL database which uses a single process per client
connection). You can implement daemons that use no multi-tasking at all
(the consist of a simple read-process-write loop that relies on the
transactions being short lived to give the appearance of multi-tasking).

A good Unix book will explain all this.

--
Jose Marques

On Mon, 12 Jan 2004, Tony Morgan wrote:

When your DLLs (often) page into memory-space used formerly by the
calling program (or another DLL), and when completed return its
memory-space to the pool? "Shared object" is a term conceived in the
wake of "OO" methodology - nothing more. And OO is merely the
formalisation of systems/methodologies/technologies that had been
previously been used for several years.

The "object" in "shared object" comes from "object code". "object code"
is the name given to the output of a compiler. The "object code" is
"linked" (ie. unresolved references are satisfied) to make a program that
can be run. The linking can occur statically (ie. a fixed set of object
code files can be made into a program) or dynamically (where the object
code is loaded into the processes address space after it has started
running). This has nothing to do with object oriented programming.

Remember Wordstar when more than 500K of program as well as data would
run in 64K of memory? And of course the well-known (then) De Smet
compiler?

Overlays are a form of virtual memory. They are not the same as shared
objects or DLLs (though again you can use shared objects or DLLs to
implement overlays).

--
Jose Marques

Thanks Jose and the rest of you for keeping this thread alive.
Hopefully Peter H. will eventually see it and answer the original
question. There has never been a way to e-mail him and I can't find
his name on any other forum except this one.

John



Jose Marques wrote in message c.uk...
On Mon, 12 Jan 2004, Tony Morgan wrote:

Multi-tasking *is* time-slicing (unless you have a one-to-one
relationship between the number of threads and number of CPUs).

No. Time-slicing is a way of implementing multi-tasking. Saying that
multi-tasking is time-slicing is the equivalent of saying that houses are
bricks. You can implement multi-tasking without time-slicing. For
example, MacOS 7.x and Windows 3.1 use coroutines to share the CPU.

Exactly. As others here have asserted - processes, program threads etc
depending on the semantics you are adopting.

No. A process and a thread are different things. A process is a CPU state
with it's own address space. A thread is a CPU state that shares its
address space with other threads.

Err.... One daemon for each thread ?

Unix didn't have threads until recently. A daemon is a process, it has
nothing at all to do with threads. It is possible to use threads within a
daemon (eg. the MySQL database uses threads to manage client connections
within a single process) but it is equally possible to not use threads at
all (eg. the PostgreSQL database which uses a single process per client
connection). You can implement daemons that use no multi-tasking at all
(the consist of a simple read-process-write loop that relies on the
transactions being short lived to give the appearance of multi-tasking).

A good Unix book will explain all this.