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

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
  - 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 -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 -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 ?



Daniel Veillard      | Red Hat Desktop team
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]