RE: Threads

[Svanberg Liss]

> 2.-In a multi-proccesor machine... wouldn't be better to have all the
> thread abstraction managed by some hurd server instead of the
> programmer.. so I can write things like this:
>
>       struct object *myobject;
>       int rst1, rst2, rst;
>       
>       myobject = new_object ();
>
>       rst =  __thread__ fgetc (stdin); /* if possible use event driven I/O
*/
>       rst1 = __thread__ do_something (&object);
>       rst2 = __thread__ do_something_else (&object);
>
>       rst += myfunction (rst1 + rst2, &object);
>
> Here "__thread__" could have a similar meaning like "register" something
> non-mandatory. Just "try to put this code in another proccesor if we

Aah! You want transparent per-function threading at the binary level!
Actually, I'm quite interested in such ideas. Don't get me wrong now,
I like your idea, but there is a problem.

The problem is the synchronisation.

In your example,
the rst* variables shouldn't be used before they have been initialized, so
the first function that tries to *read* them need to wait for them to become
*written* first.

That's the easy example, because these variables are local, the same
variable is not written from multiple scources, and no references to
them are passed around.

The hard time comes when you passes the pointer to a non-const object
to two different and possibly simultanous functions.

The only way to solve such synchronisaton problems transparently, I think,
is to add some runtime state to all variables / continious memory areas.
The needed status is whether to
lock read-write until written from {function::internal thread id},
lock writing until read from {function::internal thread id},
(and mabye lock writing until written from {function::internal thread id})

( If all programs are assumed to be written with reentracy all-over, you may
replace the internal thread id abowe with just a function id. Otherwise
you need to get the {internal thread id} from {function} when you call it. )

Note that you compiler must then realize in what order various variables
should
be acessed, because it is the compiler that ultimately must setup all this
synchronisation code.
If it fails, then everything must be called in a non-threaded way.

I think the best, and easiest way to implement this would be with some kind
of virtual memory technology, that allows us to mark parts of the memory
in states like {sleep thread if its trying to read from here}, with byte
granulary.

Today, there is no hardware avaliable that can do this...
Mabye you could let a very smart C compiler add a lot of hidden mutexes
and such, but I think this breaks something in the C spec, and you would
probably end up with an incredibly inefficient code.

So, the first thing you'll have to do, is just to design a new
byte-granular-MMU,
a new microprocessor that manages function calls as threads and handles the
thread-id part transparently, write a new C compiler, and write a new
microkernel
that the hurd can use, and then you just have to add realtime capability to
have
an absolute killer-os. :o)

// Liss
ps. If I have missunderstood what you are aiming at, please ignore this
message.
ps2. I really hope that this didn't sound rude, I'm just in a good mode
today. :)
ps3. If you find a solution to this problem, please tell me. I AM
interested!