[fpc-devel] Safely shareable objects

[Hans-Peter Diettrich]

Preface: I don't want to extend the current discussions, about threads etc.
The subject here is a possible language extension, that might allow to 
simplify the construction of shareable objects, while improving 
performance vs. already possible workarounds, optionally adding means to 
allow the compiler to assure correct and safe use of such objects.

The idea is a merge of reference counting and thread synchronization, 
which I could not find in any other language yet (dunno about ADA in 
detail), but which can be implemented easily in OPL/FPC. Inspiration 
came from TThreadList and Interfaces.

When interface references are reference counted, then it's possible to 
use the RefCount for automatic locking of the related object, so that it 
can be used by multiple threads *only* sequentially - preventing race 
conditions.

Until here everything can be achieved in every class, e.g. derived from 
TInterfacedObject, by modifying _AddRef and _Release accordingly. But 
the use of the object via interface references slows down the entire 
procedure, due to the overhead involved in calling interface methods vs. 
object methods, and the maintenance of the additional interface declaration.


I have no idea about the practical impact of that overhead, so the only 
questions are:

1. Would it make sense, perfomance-wise, to add reference-counted 
classes as a new language element?

2. Could further support be added, so that the compiler can assure that 
references to such objects can not be stored outside the calling procedure?
I.e. only local variables and parameters would be allowed to contain 
such references, because otherwise the object could be locked permanently.



Let me give an example, based on TThreadList. Such a list is intended to 
hold objects, that are for exclusive use by only one thread at the same 
time. The disadvantage is the locking of *all* list elements at the same 
time, what can either cure or create possible deadlocks. Now you may 
understand why I would like to have single objects, protected in a 
similar way. Also other organizations (pipe=FIFO, stack=LIFO...) may be 
desireable with *shareable objects*, i.e. objects that are *intended* 
for communicating data safely across thread boundaries.

Based on already available features, an IShareable interface could be 
designed, whose implementation must lock the object when its RefCount 
exceeds 1, and unlocks it again when the RefCount reaches 1 again. You 
may note the weak point: every class can implement that interface 
differently, possibly violating the implied rules. This could not happen 
when a refcounted *class* could not override the implementation in the 
base class. So let's assume that all this is implemented in a 
TShareableObject class, for use similar to TInterfacedObject, where 
nobody has to care about the implementation of the required 
interface-related (and here: thread/data synchronization related) methods.

Now we can assume that IShareable objects/references can be used all 
over the code, with no further precautions in explicit code required, 
that the use of the object *and* its content is always synchronized and 
sequentialized properly. Specific interfaces can be derived from 
IShareable, e.g. IShareableList, 
IShareableParamsAndResult<for_whatever_purpose>.

As far as FPC is concerned, the elimination of the additional interfaces 
  in above workaround IMO would not only increase the acceptance of this 
model in the design of threaded applications, but also could demonstrate 
that "Pascal rules!", increasing the acceptance of FPC/OPL as an 
outstanding compiler and language :-)

Am I too euphoric?

DoDi