I don't think there is any argument at all here. Mike is saying that no
there is not much synchronization in our system because we assume that each
thread has its own parser or that any shared parsers are synchronized at
the application level. Other than static data, of which there is a little
and it must be synchronized, we don't pay any undue overhead for
synchronization. What Mike (and I) are saying is that, for a parser to be
fully thread safe, it would have to assume the absolute worst and would
have to do huge amounts of synchronization, which everyone pays for even if
they don't need it (and most people don't because they would generally
naturally move towards the scenario that we adopted anyway.)
So, the argument of your colleague that we are not thread safe is someone
misplaced, and I would imagine that if MSXML has any reasonable performance
at all, that is follows a path not too terribly divergent from ours. I.e. I
doubt it would be thread safe at a fundamental level. And the same would
apply to Java parsers as well as C++ parsers.
----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
"Wiedmann, Jochen" <[EMAIL PROTECTED]> on 03/01/2000 11:13:37
PM
Please respond to [EMAIL PROTECTED]
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject: RE: Xerces-C Multithreading
> As Dean said, it doesn't make sense to make every call
> thread-safe. This
> would be a huge overhead, and most people wouldn't need it
> anyway (locking
> is always more efficient when done in an application-aware way).
Sorry, but I can't follow you here. Based on the assumption
of a single parser instance per thread I see no reason for
locking at all. And if parser instances are shared by threads,
its surely the task of the application to implement locking.
So why do you see a performance problem? (Of course I follow
your arguments against MSXML.)
Jochen
