[fpc-devel] Safely shareable objects

[Andrew Brunner]

2011/7/1 Adem <listmember at letterboxes.org>:
> 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.

There is no thread-safe way to write to those variables safely without
blocking access to each and every object in the entire collection as
demonstrated.

> 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.

Presently, I feel you are 100% correct.  I think with a similar case,
which did employ CS as a full fence barrier (mentioned around here
before) I had a bidirectional (double link list) problem exacerbating
any outstanding cache issues by reUsing records.  Meaning - in
addition to First,Last, I also maintain a Recycled chain.   I have a
Recycled Pointer d/l/l chain so I could recycle records and avoid
re-creating them over and over, since this is an HPC transactional
server component.

So instead of calling new, often the system would just take the first
acquire Recycled, swap with Recycled.Next, and use the Recycled
pointer.  If Recycled=nil, I would create a new data ptr.

Finally, remove is designed as LIFO.  Just a few thoughts on this
particular issue.