[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