[fpc-devel] Safely shareable objects
DrDiettrich1 at aol.com
Thu Jun 30 16:07:22 CEST 2011
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
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
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,
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?
More information about the fpc-devel