2011/7/1 Adem <listmem...@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. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
