[fpc-devel] TAVLTree(avl_tree.pp) thread safety, fcl-xml(DOM) is also concerned.
Burkhard Carstens
fpc at bcsoft.de
Thu Aug 7 11:46:43 CEST 2008
Am Donnerstag, 7. August 2008 11:28 schrieb Marco van de Voort:
> > Am Mittwoch, 6. August 2008 20:41 schrieb Inoussa OUEDRAOGO:
> > What about this:
> > * let TAVLTree access the node manager using a local reference
> > (TAVLTree.FNodeMemManager)
> > * in TAVLTree.create:
> > if IsMultiThread then
> > FNodeMemManager:=TAVLTreeNodeMemManager.create
> > else
> > FNodeMemManager:=NodeMemManager;
> > * in TAVLTree.destroy:
> > if IsMultiThread then
> > FNodeMemManager.free;
> >
> > This way, nothing would change for single threaded apps but it
> > would be fully threadsafe for multithreaded (AFAIKS). This is
> > probably not a perfect solution, but the least intrusive one ..
>
> I would add nodemgr as parameter to create, but with a default value
> of nil. If not NIL then just grab the default nodemanager.
You mean "if nodemgr = nil" then grab the global one ?
This wouldn't help much for the xml stuff or other things using avltree
internally (if there are any), unless you introduce this additional
parameter there, too.
> That way, people with multithreading concerns can override, and it is
> perfectly backwards compatible.
>
> There is no good system to do this kind of stuff automatic:
> - I might have threads but
> only read a xml config in the mainthread, no need for locks
> - I might have a dozen xml readers somewhere, and they all get an own
> pool of nodes, inflating memory. _IF_ it is multithread.
That's true, but considering the fact that it's not threadsafe at all
now .. even worse: consider a multithreaded app, that uses an avltree
in one thread and a xmldocument in another thread ... this would give
hard to find strange errors and the user (developer) doesn't even see a
relation between avltree and xml, unless he digs into xml sources ..
However, see my other reply to my own post: using "IsMultiThread" won't
work anyway so I already refrained from auomatic handling.
regards
Burkhard
More information about the fpc-devel
mailing list