[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