thread safety of pointers e.g. *regexp.Regexp

[Mark Summerfield]

Hi,

I want to use the same regular expression concurrently in several
goroutines.

But the regexp package's documentation does not specify whether
*regexp.Regexp values are thread safe.

So, I must assume that they are not thread safe (i.e., calling
*regexp.Regexp methods might change the pointed to value's internal
state).

I think it would be helpful if the documentation specified which types
that are accessed through pointers are thread safe and which aren't.
(Unless none of them are of course.)

For now I'll give each goroutine the string from which the regular
expression is compiled and have them create their own.

Regards.
--
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
C++, Python, Qt, PyQt - training and consultancy
"Advanced Qt Programming" - ISBN 0321635906
http://www.qtrac.eu/aqpbook.html

[bflm]

On Jun 28, 10:28 am, Mark Summerfield <l...@qtrac.plus.com> wrote:
> I want to use the same regular expression concurrently in several
> goroutines.
>
> But the regexp package's documentation does not specify whether
> *regexp.Regexp values are thread safe.
>
> So, I must assume that they are not thread safe (i.e., calling
> *regexp.Regexp methods might change the pointed to value's internal
> state).
>
> I think it would be helpful if the documentation specified which types
> that are accessed through pointers are thread safe and which aren't.
> (Unless none of them are of course.)

What's wrong with reading programs? Source code does count IMO as a
documentation also. What of the fields can be expected to mutate
within methods of an already compiled regexp?

http://golang.org/src/pkg/regexp/regexp.go?s=5238:5613#L151

// Regexp is the representation of a compiled regular expression.
// The public interface is entirely through methods.
type Regexp struct {
expr string // the original expression
prefix string // initial plain text string
prefixBytes []byte // initial plain text bytes
inst []*instr
start *instr // first instruction of machine
prefixStart *instr // where to start if there is a prefix
nbra int // number of brackets in expression, for
subexpressions
}

My quick *guess* is: none of them. To be sure, one can check the
specific method in question and look there (+ what it calls,
naturally).

[Peter Bourgon]

> What's wrong with reading programs?

Analysis of types for thread-safety is a non-trivial enterprise, even
for their original authors. Expecting all users of a language to
determine for themselves if a given context struct is threadsafe by
reading the implementation of the package is probably not reasonable.

A simple rule would be sufficient: Go standard library packages are
not threadsafe, unless otherwise explicitly noted. Is that accurate?

[Gustavo Niemeyer]

>> What's wrong with reading programs?
>
> Analysis of types for thread-safety is a non-trivial enterprise, even
> for their original authors. Expecting all users of a language to
> determine for themselves if a given context struct is threadsafe by
> reading the implementation of the package is probably not reasonable.

Indeed. Plus, the question is not whether it is thread safe or not
today, but whether the authors promise to maintain safety. Code
shouldn't be assumed to be thread safe unless the guarantee is
explicitly stated.

> A simple rule would be sufficient: Go standard library packages are
> not threadsafe, unless otherwise explicitly noted. Is that accurate?

Yes, and that's valid for pretty much any software.

--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/blog
http://niemeyer.net/twitter

[bflm]

On Jun 28, 11:19 am, Peter Bourgon <peterbour...@gmail.com> wrote:
> > What's wrong with reading programs?
>
> Analysis of types for thread-safety is a non-trivial enterprise, even
> for their original authors. Expecting all users of a language to
> determine for themselves if a given context struct is threadsafe by
> reading the implementation of the package is probably not reasonable.

The OP was not about any general situation but very specifically about
a concrete type. Expecting a programmer to understand code he/she is
using is nothing special. And there's e.g. not a single go statement
in the regexp package.

> A simple rule would be sufficient: Go standard library packages are
> not threadsafe, unless otherwise explicitly noted. Is that accurate?

No, that's only safe, nothing more. Such approach can/must lead to
unnecessary resource use (with any type which is in reality "safe").
Then people start to blame the language for poor performance instead
themselves because they are writing poor code.

If on can see in a specific case the obvious "thread safety" of some
concrete type in Go, then it's wrong to treat that type in the other
way. That IMO holds even where that guarantee is not explicitly
stated. Either because it seemed obvious to the package author(s), or
it can be just an omission. In the later case there is:

http://code.google.com/p/go/issues/list

and this:

http://golang.org/doc/contrib.html

for anyone to use.

Any future changes to a package code which may turn some "safe" type
into an "unsafe" one are normally announced in the changelist and
client code can be adjusted afterwards.

----
"There are 10 kinds of programmers. The other kind can't even read
binary."

[Rob 'Commander' Pike]

It should be safe. Execution state is kept separate from the *Regexp.

-rob

[Mark Summerfield]

Thanks! Nonetheless, I'll stick with creating the regex from the pattern
string once per goroutine on the grounds that if it isn't documented as
thread-safe then no promise has been made.

I feel strongly that the public API and its documentation are all that
one should rely upon. I'm happy to look into the source code to learn
how things are done (and godoc makes this particularly easy which is v.
nice), but never as a means of "optimizing" on the basis of a particular
implementation that might change at any time:-)

--
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
C++, Python, Qt, PyQt - training and consultancy

"Programming in Go" - ISBN 0321774639
http://www.qtrac.eu/gobook.html

[Russ Cox]

> Thanks! Nonetheless, I'll stick with creating the regex from the pattern
> string once per goroutine on the grounds that if it isn't documented as
> thread-safe then no promise has been made.

I promise it's safe.

We'll fix the docs.

[Rob 'Commander' Pike]

That's silly. I'm telling you it's safe.

> I feel strongly that the public API and its documentation are all that
> one should rely upon. I'm happy to look into the source code to learn
> how things are done (and godoc makes this particularly easy which is v.
> nice), but never as a means of "optimizing" on the basis of a particular
> implementation that might change at any time:-)

Docs will be fixed.

-rob

[Mark Summerfield]

OK, a promise is good: I'll create one regex and share it:-)

> We'll fix the docs.

Thanks!

[san...@gmail.com]

Rob,

This is almost 3 years later. Is *Regexp still thread-safe, and do you still plan to fix the docs?

Thanks.

[Caleb Spare]

From the docs:

A Regexp is safe for concurrent use by multiple goroutines.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Gerald Sangudi]

Thanks, I missed that.