[Lazarus] thread safe

[Andrew Brunner]

2011/6/22 Malcom Haak <insanemal at gmail.com>:
> Correct me if I'm wrong, But can't you technically make any code
> 'thread-safe'  by using Critical Sections before doing work.
> In some code I have seen before a critical section was entered before
> calling TList.Add
> Now provided that you don't need a specific order, does this not then make
> it thread safe?
>

Partially.  Read barriers may not be necessary.  It depends on the
implementation.  By having barriers placed at strategic locations in
the code, you can make an implementation thread safe.

Add, Delete, and Clear would be some.  List iterations would be
difficult if not unsafe outside a lock but if accessed under a manager
thread you can schedule and operation and it will wait done until
conditions are safe to perform.

Getting an item from the list rather than locking the entire list and
having an inUse boolean set to true for that item, would allow for any
deletion to be blocked until another time (by a manager thread).

With multi-core systems simply adding a mutex/lock is not enough.  A
manager is needed to be in place to safely provision, delegate, and
use items.  IMO, this forces efficiency in a system design.  The basic
logic for a manager thread is that the manager thread is accepting
commands, and scheduled execution happens automatically.

Further, you could create a command system for each list so when you
add/remove an item from the list you are merely scheduling that item
for deletion. I would avoid polling for large lists.  The command
should have a completion routine like Item.onComplete(Item) where the
item is passed for use in the application.

This way there would be absolutely no waiting for data in code and the
system in general at rest until needed.