[Lazarus] thread safe

[Hans-Peter Diettrich]

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