OS4 and Threads

[DaveP]

Well this has been debated to death on another thread.

Threads are analagous in AmigaOS as exec "Tasks"
and behave in almost exactly the same way.

However Thomas Frieden was on here ( or was it HJ? )
and pointed out that there is a flaw exposed ( whether it
is in Exec or in Amitcp ) when sharing a socket descriptor
which is pretty vital given that an accept( ) call returns
a client side socket descriptor which you normally
spawn off onto a subtask and let that handle it.

On z/OS there is a special call that puts the socket
descriptor into the OS and one that gets it back to
get round a memory sharing issue.

Can't say Ive checked his claim out but thats about it.

Threads share memory with the parent - so do tasks
Threads die with the parent - tasks don't always
Some OS are "Thread scheduled" - AOS is "task scheduled" ( sort of )

But AOS goes a bit further than this in that all all tasks
can "share memory" by passing pointers around and the
alien task can navigate through the structure at will
having been given a pointer to another tasks address space.

This is the much vaunted problem with MP. If we have MP
it has to be more intelligent than other MP schemes because
we have to authorise another task to our address space
in order to avoid breaking "memory sharing" aspects of
message passing.

But I digress...

[DaveP]

Oh and the other bit about thread scheduling being
faster than process scheduling is a bit of a myth really
but as with all myths there is some truth down there.

In order to make "process scheduled OS" where each
process has its own seperate address space ( and
children have a COPY of the parent address space )
context swaps when changing between processes
involve not only the execution thread being exchanged
but the address space too.

If the context swap is to another thread within the same
process then in a thread scheduled environment only
has to switch the execution thread.

Problem is in reality you have to design your multi-tasking
algorithm for the most efficient use of the system.

Not all context swaps between threads will be threads
in the same process and not all process swaps are expensive
in supervisor mode.

Did I explain that OK or should I put a worked example in?

[DaveP]

@Rogue

Yes, aware of the fact you cant share library bases
but that does not make a Task less of a Thread. What
you are talking about here is an implementation limitation
of the way libraries are implemented in AmigaOS. There
are fun implementation flaws in pthreads on AIX and W32 threads
as well.

"The question isn't really whether you schedule threads or tasks - you need to do both."
...to implement it efficiently...

" Threads are scheduled at a higher frequency, and only within the currently running task."
...in certain implementations...

[DaveP]

"OS 4 supports real threads. "

Which means what? I could understand it if you said
OS4 supports POSIX threads, or OS4 supports threads
in the context of definition X,Y,Z but I find "real" a
bit misleading and too general.

[DaveP]

Thread: A portion of a program that can run independently of and concurrently with other portions of the program.

I thought I was maybe being a bit presumptious in
tackling H-J F over the use of "Real" threads. So I went along to dictionary.com to see what kind of a definition they had there.

Exec tasks can be used like threads as defined here.

Hmm.

I guess what you were getting at H-J F is that a threading implementation will be available which is
much closer to what people with a pthread or
a WinNT/2K/XP background are used to in terms of
what it can do and the life-cycle of the thread.

I looked a bit into MTF which is the MVS Task system
which I remembered had problems with socket
descriptors. It seems it is a similar issue with access to devices on a subtask. That is why
the sockets interfaces ( plural - there are a few of them in there!! ) have the option to pass the descriptor back to CommsServer and pull it back
again.

But MTF tasks are more isolated from the parent
task than Exec in the first place - making them
more like "Processes".

I quite like not thinking in terms of threads and processes on the AmigaOS. Makes a change from work!

In fact it was the nomenclature of Amiga that hooked
me in the first place ;-)