[protobuf] Message thread safety in Java
Hi, 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? Thanks! Br, --Frank -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] Message thread safety in Java
On Feb 20, 2012, at 8:25 , Frank Durden wrote: 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. http://www.ibm.com/developerworks/java/library/j-jtp02183/index.html 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? Evan -- http://evanjones.ca/ -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] Message thread safety in Java
The documentation says it's immutable: http://code.google.com/apis/protocolbuffers/docs/reference/java-generated.html#messageand this code is heavily used in production, so you can bank on that. 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] Message thread safety in Java
Message objects *don't* have mutators and are conceptually a copy of the relevant builder object. --Chris On Feb 20, 2012, at 10:22 AM, Tom Swirly t...@swirly.com wrote: The documentation says it's immutable: http://code.google.com/apis/protocolbuffers/docs/reference/java-generated.html#message and this code is heavily used in production, so you can bank on that. 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] Message thread safety in Java
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: http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.4 http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.5 -- http://evanjones.ca/ -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
