I'm sorry if this is explained somewhere, I couldn't find an answer.
Are protobuf messages (in Java) thread safe for concurrent reads. I
guess they're immutable in the sense that you can't modify them after
they're built, but can a message object content be read from different
threads safely? The generated variables in message objects don't seem
to be final or volatile?
> I'm sorry if this is explained somewhere, I couldn't find an answer. > Are protobuf messages (in Java) thread safe for concurrent reads. I > guess they're immutable in the sense that you can't modify them after > they're built, but can a message object content be read from different > threads safely? The generated variables in message objects don't seem > to be final or volatile?
After you call .build() and get a Message, that message is immutable, as you observed. I'm not a Java memory model expert, but my understanding is that despite the fields not being market final, this is in fact thread-safe. However, my only support is this quote from Brian Goetz:
"With some additional work, it is possible to write immutable classes that use some non-final fields (for example, the standard implementation of String uses lazy computation of the hashCode value), which may perform better than strictly final classes."
I'm pretty sure the right people at Google have examined the protobuf code, so it should be safe. However, I don't have a good argument for *why* it is safe. Maybe someone who is a Java memory model expert knows the reasoning here?
The only way I can see that this would be accomplished would be by returning a *copy* of the underlying protocol buffer, wrapped in something without mutators. Copying protocol buffers is quite cheap and this wouldn't require volatile or any locks to work. But I don't have access to code right here, right now to check this...
> The only way I can see that this would be accomplished would be by returning a copy of the underlying protocol buffer, wrapped in something without mutators. Copying protocol buffers is quite cheap and this wouldn't require volatile or any locks to work. But I don't have access to code right here, right now to check this...
> -- > You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. > To post to this group, send email to protobuf@googlegroups.com. > To unsubscribe from this group, send email to protobuf+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
On Feb 20, 2012, at 16:20 , Christopher Smith wrote:
> Message objects *don't* have mutators and are conceptually a copy of the relevant builder object.
Having attempted to refresh my knowledge of the Java Memory Model, I think there is a subtle difference between an object that has all final fields, and an "immutable" object like the protobuf messages. However, I don't think it matters in reality: As long as the message is "correctly published" to other threads (eg. a synchronized block, volatile reference, concurrent data structure), then everything is fine. Since everyone *should* be doing this already, Messages are safe to use across multiple threads.
Evan
PS. For language lawyers: I *think* the potential difference is as follows: Writes to final fields in a constructor are guaranteed to be visible to all threads when the constructor exits. So if you had the following:
static FinalImmutableObject someRef = ...;
Then if another thread sees a non-null value for someRef, it will correctly see all the values of the final fields. On the other hand, if you do this with a protobuf message, it *theoretically* could see a non-null value for someRef, but still see uninitialized or incorrectly initialized values for fields in someRef.
This is because this static variable is not synchronized or volatile, so there is no "happens-before" relationship between two threads. Thus, the reads on one thread *could* be reordered before the writes on the other thread. References:
Ok guys thanks for all the responses. Having studied this a bit more
closely I can recap that protobuf messages are what's called
"effectively immutable" (according to terminology used in Brian
Goetz's book p.52-53) and need to be "safely published" to be used
across multiple threads. Just like Evan said in his second post.
