2011/6/22 Malcom Haak <[email protected]>: > 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. -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
