Re: [xml] Re: Thread-safety of XSLT contexts with shared dictionaries

[Daniel Veillard <veillard redhat com>]

On Fri, Jan 21, 2005 at 04:22:18PM +0000, Gary Coady wrote:
> Daniel Veillard wrote:
> >  Yup I knew about the potential problem, but it wasn't clear it would end
> > up being a serious one. I agree that the most generic solution is to
> > use mutexes to avoid race in the increment/decrement. I'm not sure however
> > that a global mutex is the best thing. One mutex per dict would avoid 
> > any initialization race and avoid a global contention point for all threads
> > while there really should not be global. It is a trade-off between:
> >   - cost of creating a mutex
> > and
> >   - cost associated in being blocked on a global mutex
> >
> > I would expect the cost of creating a mutex to be extremely low on
> > processors/arch with atomic test-and-set operations (and SMP cache
> > invalidation), on the other hand the cost of a global mutex rise quickly
> > precisely for the programs where threading is intensive and where that
> > mutex is really needed.
> > Any chance you could make another patch where the mutex is in the 
> > xmlDict structure and initialized in xmlDictCreate(). Also never put
> > a patch in the mail content dicrectly, add it as an attachment otherwise
> > the mail programs destroy it so much that patch(1) refuses to apply it.
>
> Good point, here's another patch which works in my test setup.

  Applied, seems to give around 2% performances loss in kind of worse
case tests but it's bearable since it an exact solution to a nasty to debug
race otherwise.

  before (best of 5 tests)

test64:~/XML/xstc -> time nist-test.py -s -b .
Ran 5430 of 5430 tests: 500 failed 48 unimplemented

real    0m3.301s
user    0m2.879s
sys     0m0.422s
test64:~/XML/xstc ->

  after (best of 5 tests)

test64:~/XML/xstc -> time nist-test.py -s -b .
Ran 5430 of 5430 tests: 500 failed 48 unimplemented

real    0m3.358s
user    0m2.951s
sys     0m0.407s
test64:~/XML/xstc ->

  Commited. But it would be interesting to see if the global lock one 
would lead to less performance losses on non threaded applications, could
you send again the first patch but as an attachment ?

  thanks,

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/