[fpc-devel] Safely shareable objects

Adem listmember at letterboxes.org
Fri Jul 1 21:28:23 CEST 2011


On 2011-07-01 18:49, Hans-Peter Diettrich wrote:

> Such a beast would deserve many coding efforts, which are unlikely to be
> ever taken. It's much simpler to control existing references to an
> object, since every use of an object deserves an object reference.

In a double-linked list (or a treeview kind of structure), a simplified 
Attach() procedure looks like below:

     FNextSibling := AParent.FNextSibling;
     AParent.FNextSibling := Self;
     FPrevSibling := AParent;
     FParent := AParent.FParent;
     if FNextSibling = nil then FParent.FLastChild := Self
     else FNextSibling.FPrevSibling := Self;

Now, in this piece of code we have the following 9 variables (each one a 
node object):

FNextSibling
FNextSibling.FPrevSibling
FParent
AParent
FParent.FLastChild
AParent.FNextSibling
AParent.FParent
FPrevSibling
Self

In a multi-core multi-threaded platoform, I simply cannot see (other 
than locking the whole object) how any amount of interlocking or 
critical sections (or whatever) can guarantee that none of these 9 
variables (nodes) will not be altered/deleted while we're in Attach() 
procedure.

And, the problem isn't just the Attach() procedure, any thread (running 
on a different core) that reads any property (such as FirstChild, 
LastChild, NextSibling, Parent, PrevSibling etc.) of this node object 
cannot be guaranteed to get valid values.

BTW, the problem --as I see it-- isn't limited to double-linked lists; 
any object that that gets shared across threads running on different 
cores will have similar problems; it's just that nodes in double-linked 
lists (or treeviews) highlight the problem better than anything else I 
can think of right now.

> No woman - no cry ;-)

Is that similar to "no pain, no gain" ;)



More information about the fpc-devel mailing list