Marco van de Voort schrieb:
On Mon, Jun 27, 2011 at 03:05:36PM +0100, Hans-Peter Diettrich wrote:
OOP is just a convenient abstraction, it's for people needed only :)
OOP is for designers, not for hackers ;-)
When some thread-safe code must never bring a program (automaton,
system...) into an inconsistent state, objects are fine to break down
the entire program into self-contained sub-systems. This allows to
dramatically reduce the degree of freedom of the entire ("flattened")
problem. Whatever can be done entirely inside an object, deserves no
further consideration of everything outside the object.
Are you talking about monitors? How else will you force an object with only
one thread in it?
Or are you meaning thread+TLS+state exclusively used in the thread as
object?
I'm not talking specifically about threads here, instead of OOP and
program design in general. An interactive program is much harder to
control than a batch-style program with almost sequential control flow.
When you try to create a state/transition diagram (automaton, state
machine), with allowed actions and transitions for every possible state,
then this will be almost impossible for an interactive program (too many
possible states). When that huge automaton is broken down into
sub-automatons (objects), with their own internal states and
transitions, then the overall application will have to respect only a
fraction of the total possible states. Every object will settle down in
a limited set of allowed states, and the logic of the main program must
not deal with the many *intermediate* states, that may occur inside an
object.
Imagine a file object, that may implement included files, an undo list
and whatever you like. Such an object includes many sub-objects
(lists...) and variables (file positions, undo pointers...), which can
be in very many different states (values). But those states, that are of
interest to the controlling program, can be restricted to simple
informations like IsOpen:boolean, and all further validity checks and
transitions can be encapsulated in the publicly accessible methods
(actions).
This model can be extended for threads, where a single test for e.g.
obj.Locked will reveal whether access to *all* of the object's members
is currently allowed. When such objects know about related objects, that
will be accessed during some operation (method call), the number of
these objects will be much lower than the number of variables, that had
to be locked *individually* before the operation can start. That reduced
number of dependencies will simplify the implementation of strategies
for deadlock prevention and resolution.
I've been following this subthread for a couple of posts yet, and the whole
picture leaves an vague feeling.
ACK. Using threads requires more than only TThread objects, which are
useless without a reliable thread synchronization model, *and* an
according implementation of this model in application specific code.
DoDi
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
