Author Topic: OS4 and Threads (Read 2232 times)

star1 · « **on:** February 13, 2003, 06:26:58 AM »

Hi everyone,

just wondering if OS 4 has features as threads?

I heared that threads execution is faster than regular process execution..

If not can threads be implemented in OS 4.x or is it not possible at all??

Linux and Mach kernel seem to have it...

I was just wondering, Amiga is so fast without threads just imagine with it :-o :-o :-o

Please clarify on this issue and elaborate if OS4 can up to parr with Mach Linux ...

@Ben

I know you know alot about this please drop some lines on this

Thanks .

samdu · « **Reply #1 on:** February 13, 2003, 06:41:36 AM »

I thought AOS was multithreaded?!?

DaveP · « **Reply #2 on:** February 13, 2003, 07:40:08 AM »

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 · « **Reply #3 on:** February 13, 2003, 07:45:50 AM »

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?

Mr_Capehill · « **Reply #4 on:** February 13, 2003, 09:40:27 AM »

It was discussed a bit while ago on OS 4 mailing list. I have understood that the threads are implemented already, or coming with updates at least. Ask Friedens for more information :-)

Rogue · « **Reply #5 on:** February 13, 2003, 11:52:18 AM »

Quote

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

I think that was Thomas. Yes, some implementation of bsdsocket cannot share a socket between tasks since they use task signals. This is a general problem, not really a flaw in the bsdsocket implementation. According to the docs, you cannot even share library bases over tasks.

OS 4 supports real threads.

The question isn't really whether you schedule threads or tasks - you need to do both. Threads are scheduled at a higher frequency, and only within the currently running task. Tasks OTOH are scheduled like before.

DaveP · « **Reply #6 on:** February 13, 2003, 12:43:35 PM »

@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 · « **Reply #7 on:** February 13, 2003, 01:18:03 PM »

"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.

Cymric · « **Reply #8 on:** February 13, 2003, 02:44:53 PM »

@Rogue:

'OS4 supports real threads.'

What kind of threads? There's for example kernel space threads where threads are scheduled by the operating system and thus can run in parallel. You have user space threads where threads are scheduled by the application itself with minor help from the operating system, and thus can not run in parallel. (To avoid confusion: with 'in parallel' I mean that to the OS, there are more tasks based on the same parent running. With user space threads, the operating system sees just one task: the parent.) You even have complex systems where both are combined.

In addition, Linux has a most elegant design where the user can select which resources are shared between the thread and its parent: memory, signals, file descriptors, and a few more. I'm sure that other operating systems have their variants. So there's quite a number of options to choose from. Can you elaborate on the type implemented in OS4?

DaveP · « **Reply #9 on:** February 13, 2003, 04:42:48 PM »

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 ;-)

Author Topic: OS4 and Threads (Read 2232 times)

star1

OS4 and Threads

samdu

Re: OS4 and Threads

DaveP

Re: OS4 and Threads

DaveP

Re: OS4 and Threads

Mr_Capehill

Re: OS4 and Threads

Rogue

Re: OS4 and Threads

DaveP

Re: OS4 and Threads

DaveP

Re: OS4 and Threads

Cymric

Re: OS4 and Threads

DaveP

Re: OS4 and Threads