[fpc-devel] TAVLTree(avl_tree.pp) thread safety, fcl-xml(DOM) is also concerned.

Marco van de Voort marcov at stack.nl
Thu Aug 7 11:52:08 CEST 2008

> Am Donnerstag, 7. August 2008 11:28 schrieb Marco van de Voort:
> >
> > 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.

Correct. But better do it correct directly. The kind of workarounds
described here are fine for a single app, but not something you put in libs.
> > 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 ..

If you are so worried about that, give the XML units an own avl node mgr,
that they always pass. But IMHO doing it right is important now.

Btw, this is also one of the reasons why I never do significant work in a
constructor. This way, you always have to expand parameters in the
constructor, facing incompabilities and inheritance problems. 

If the constructor doesn't do stuff like loading the file, you can simply
use a setter.

More information about the fpc-devel mailing list