RE: Objects, processes, and encapsulation

["Hilderink, G.H." <G.H.Hilderink@xxxxxxxxxxxxx>]

Hi Øyvind,

Processes and threads have little in common. 

Threads cannot deadlock, processes do! 

Systems can deadlock, applications can deadlock, active objects can
deadlock, ... everything that has a life of its own and that is meaningful
can deadlock. I wonder if I can deadlock???? I wonder how that would look
like :). Hehe, people are deadlock free, I guess. Threads simply drive our
processes and threads belong to the invisible environment. It is the
processes, objects, and events *we* are interested in. Only the processor
(environment) is interested in threads and it is not interested in
processes, objects, and events.

Threads have no structure, processes have! 

A person who drives a car is performing multiple sequences of actions. Each
sequence of actions is a thread of control. In this example the car is an
object and the actions performed by the driver (processor) correspond to the
threads of control. Together they form a process. These threads of actions
have no structure. However, a thread on a processor seems to have a
structure, but this structure tells all about the scheduler than about the
thread of control. Also, priority is a scheduling parameter under control of
the scheduler and not under control of the associated thread. If a thread
had a structure then it should maintain its structure, well, it does not.
Hmm, it doesn't harm to argue that a thread implementation has a structure
since such structure is invisible to the application and to us.

Please, argue with me if I go wrong here?

Well, I don't plea that threads are bad and processes are good. We need
threads to execute our processes. My message is that the original and clean
OO paradigm has been corrupted by the multithreading paradigm. This is
simply by the fact that multithreading is NOT OO (oops did I repeat that
again :)) and has become a source of unnecessary complexity in OO. As you
know CSP fixes this, because it separates concerns in a clean an elegant
way. 

Objects as defined by most OO programming languages have little in common
with processes since processes should be treated differently from objects.
This is similar as with message passing which is forced to be simple method
calls. However, the original idea of objects has lots more in common with
processes than present objects. Also message passing has lots more in common
with channel communication than present method calls. The original idea of
objects was that objects are concurrent entities, but this promise seemed to
be an illusion. Fortunately, some people came up with better names for
'active' objects like skeletons, capsules, agents, actors, etc. with
associated design patterns. These are all processes. Although these are good
ideas, their implementations become corrupted by multithreading and
sequential programming languages. Hmmm, OO is going the wrong way, damn
multithreading!

Just a thought...

Gerald.