Clarify thread-safety of Span

[raskam]

Background

I was not able to find any notes on thread-safety of Span in the Specification, nor in opentracing-java.

Problem

I'm not sure if I could use single Span instance in a concurrent environment. When discussed on Gitter with @jpkrohling, he said he would expect it to be thread-safe, but in practice it is probably implementation-specific as thread-safety it not explicitly addressed in the Specification.

Considering operations from opentracing-java

• I guess the Span#finish operation can be thought of as thread-safe as it should be called only once
• I'm not sure about other operations (Span#log, Span#setTag etc.)

For other Data Models I've found that

• SpanContext is thread-safe, because is it required to be immutable by Specification
• Scope (opentracing-java concept) is not thread-safe, as mentioned in https://github.com/opentracing/opentracing-java#deferring-asynchronous-work

Proposal

Clarify in the specification, whether OpenTracing implementations should (or must) implement Span and it's operations in a thread-safe manner. And vice versa, if thread-safety is intentionally implementation dependent, it should be mentioned in the docs (or opentracing-java at least)

Thanks!

[isaachier]

SpanContext cannot be immutable in C++ due to opentracing/opentracing-cpp#74. I changed Jaeger client to use locking there.

[carlosalberto]

Now being discussed in #120 ;)