[ruby-talk:10782] Re: Suggestion for threading model

In message <[e-mail]>
[e-mail] writes:

> Here's a possible implementation:
(snipped ....)
> This would incur the cost of one C style variable check per object reference
> and slow method calls would have an additional context switch.

I understand your proposal as a naive concurrent object model ---
every object behave as a server or something like an actor, which
processes request messages one at a time --- with more realistic and
probably more efficient implementation.  In that line, a program can
be seen as constructed from normal threads and static objects.

Threads of control does not belongs to any objects, and an object are
not an active entity but an aggregate of static data and opertions on
data.


> > 3. Most important one: Is that model really so useful?
> 
> I don't know. It would depend on the situation. This scheme doesn't help
> with OS threads or multiple CPUs but it does have the advantage of being
> automagic. :)

With above assumption, then again, why we choose a model that is far
from an internal implementation, which has contraversely a well-fit
model?

It doesn't depends on wheather threading is implemented in kernel,
which relatively heavy weight, or user level library realizing very
light weight and optimized for ultra fine grain threads like stack
threads.


I personally think a current programming model, where no implicit
parallelism, is good enough, and what actually needed is well designed
synchronization mechanism and easy-to-use libraries around it --- for
example a mix-in module for implemtnting a monitor, a barrier like
construct to wait multiple threads each other, library providing more
fine grain constraints on method calls, etc.

# Do not seriously recieve that fire-and-forget type of words :-P  I
# don't think so deep yet....


-- 
[e-mail]                              February 13, 2001
He knows most who speaks least.