|
Boost : |
Subject: Re: [boost] Is Boost.Xpressive's sregex::compile() thread-safe for an object only used in that thread?
From: Eric Niebler (eniebler_at_[hidden])
Date: 2014-12-12 03:09:50
On 12/11/2014 2:35 PM, Chambers, Matthew wrote:
> I have a case where I am compiling a dynamic regex based on client code
> input, and it works except for when I run my multi-threaded unit test
> 100-1000 times.
>
> When I run it with 1 thread, it never fails. When I run it with 2 or 4
> threads it fails at this rare frequency. Except on my build server,
> where it seems to fail most of the time, which is how I learned about
> the issue to begin with. It's not crashing though, it's just very rarely
> returning the wrong results, and not always in the same place in the
> unit test.
>
> So I'm trying to understand Xpressive's thread safety. I understand it
> as far as not using a regex object in multiple threads until it's
> finished compiling and not sharing a match_results across threads, but
> what about compiling different regex objects for each thread: if two
> threads are compiling two different regexes (or even the same const
> regex string but from different threads, which is possible with my test
> code), is that ok?
>
> I'm seeing this failure on MSVC 12 but I think I also got it with VC10,
> just not as reliably on the build server (but the build server had to be
> upgraded to Windows 2012 to install VC12, so maybe that OS change had an
> effect as well).
Are your regex objects referring to other regex objects? That is, are
you defining a grammar? See this caveat in the docs:
The docs only mentions static regexes, but it's true for dynamic regexes.
If you're not building grammars where some of the regexes are shared,
then no, there are no known thread-safety problems with constructing a
regex on a single thread.
After the regex object is constructed, it is safe to use from multiple
threads, since it's not mutated during pattern matching.
HTH,
Eric
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk