Re: Thread-safe ORO

["Daniel F. Savarese" <df...@savarese.org>]

>since i needed regex in a multithreaded environment, i modified ORO in a
>quite simple way. The version here is now completely instantiated and
>unsynchronized. Tests in threadalizer and by running in several parallel
>threads look fine. If this could be interesting for the repository, just
>tell me.

First, you should send this email to oro-dev and not to me at oro-dev-owner.
I've been bleeding email from jakarta mailing lists for two weeks because
of the change to nagoya (too many details to get into), so if you've sent
previous emails to oro-dev that required moderation approval, I didn't
get them and apologize.

Second, jakarta-oro's .text.regex package is designed to work correctly
and efficiently with multiple threads (search the archives for a discussion
of why people misunderstand the meaning of thread-safe).  Synchronization
is avoided wherever possible.  You should use a separate matcher and compiler
for each thread (unless you precompile your patterns, in which case you only
need a separate matcher per thread).  If you want to share a pattern
between threads, compile with READ_ONLY_MASK (assuming you're using the
.text.regex package, otherwise no extra flag is needed).  This is
intentional and maximizes opportunities for optimizing performance.  If
you want something "easy to use" but less efficient use Perl5Util.  In any
case, no, if your modifications add synchronization to the .text.regex
package they will not be considered because they violate the design
principles of the package.  However, if you've developed a factory that
makes it easy for people who don't understand they shouldn't be repeatedly
instantiating matchers every time they need them to share a single one
between threads, then, yes, that would be considered.  But the best thing
to do is to post a diff or URL pointing to a diff to oro-dev because it's
the only way to ensure we really understand your suggestion and can discuss
it without rejecting it prematurely.  Even if a suggestion is rejected,
it may lead to a more evolved version through discussion and ultimately
be incorporated.

daniel



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Thread-safe ORO

[Michael Remme <mr...@braintags.de>]

Oops, i'm sorry, Daniel, for sending the mail directly to you, this wasn't
my intention. I just put down in the mailing-list and by accident used a
wrong email-adress from the welcome-message. Sorry again.

Of course, before starting to make my modifications, i searched the archive
and i found and read your message. When i looked into the code, i saw, that
every call to substitute, for instance, is sent to the static
Util.substitute and from there to some other, partially synchronized
methods. And there i don't see a synchonization problem, but a possible
block for threads, which are working parallel with larg textfiles to
substitute.

Best, Michael

> >since i needed regex in a multithreaded environment, i modified ORO in a
> >quite simple way. The version here is now completely instantiated and
> >unsynchronized. Tests in threadalizer and by running in several parallel
> >threads look fine. If this could be interesting for the repository, just
> >tell me.
>
> First, you should send this email to oro-dev and not to me at
> oro-dev-owner.
> I've been bleeding email from jakarta mailing lists for two weeks because
> of the change to nagoya (too many details to get into), so if you've sent
> previous emails to oro-dev that required moderation approval, I didn't
> get them and apologize.
>
> Second, jakarta-oro's .text.regex package is designed to work correctly
> and efficiently with multiple threads (search the archives for a
> discussion
> of why people misunderstand the meaning of thread-safe).  Synchronization
> is avoided wherever possible.  You should use a separate matcher
> and compiler
> for each thread (unless you precompile your patterns, in which
> case you only
> need a separate matcher per thread).  If you want to share a pattern
> between threads, compile with READ_ONLY_MASK (assuming you're using the
> .text.regex package, otherwise no extra flag is needed).  This is
> intentional and maximizes opportunities for optimizing performance.  If
> you want something "easy to use" but less efficient use Perl5Util.  In any
> case, no, if your modifications add synchronization to the .text.regex
> package they will not be considered because they violate the design
> principles of the package.  However, if you've developed a factory that
> makes it easy for people who don't understand they shouldn't be repeatedly
> instantiating matchers every time they need them to share a single one
> between threads, then, yes, that would be considered.  But the best thing
> to do is to post a diff or URL pointing to a diff to oro-dev because it's
> the only way to ensure we really understand your suggestion and
> can discuss
> it without rejecting it prematurely.  Even if a suggestion is rejected,
> it may lead to a more evolved version through discussion and ultimately
> be incorporated.
>
> daniel
>
>
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>

Virengeprüft vom G DATA AntiVirenKit


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>