Compiling protobuf with GOOGLE_PROTOBUF_NO_THREAD_SAFETY macro

[Safi Ali]

Hi,

I have been trying to compile google protocol buffers 2.5.0 on solaris (sparc) environment. It seems I have to use the GOOGLE_PROTOBUF_NO_THREAD_SAFETY macro in order to make it compile properly. So I follow these steps to compile protobuf:-

./configure CPPFLAGS="-DGOOGLE_PROTOBUF_NO_THREAD_SAFETY"

make 

make check

In 'make check', all tests pass. 

Can anyone shed some light on what are the caveats of using the no_thread_safety macro? What, if any, problems can I expect from protobufs with no thread safety. I have some apprehensions about it and it would be great if someone could clarify those for me:-

1. Is the thread safety only an issue during compilation of .proto files to java/c++ source files? or does protobuf also rely on thread safety during execution of compiled code?

2. If I dont use thread safety, does protobuf gracefully fall back to single threaded model where needed, or still try to use threads but in somewhat "unsafe" fashion which can lead to bugs such as deadlocks if im unlucky?

3. How is the performance affected while using thread unsafe code? if anyone has done some benchmarking, would be good to see the results.

Regards,

Safi

[Feng Xiao]

On Mon, Oct 21, 2013 at 1:05 AM, Safi Ali <safi...@gmail.com> wrote:

Hi,

I have been trying to compile google protocol buffers 2.5.0 on solaris (sparc) environment. It seems I have to use the GOOGLE_PROTOBUF_NO_THREAD_SAFETY macro in order to make it compile properly. So I follow these steps to compile protobuf:-

./configure CPPFLAGS="-DGOOGLE_PROTOBUF_NO_THREAD_SAFETY"

make 

make check

In 'make check', all tests pass. 

Can anyone shed some light on what are the caveats of using the no_thread_safety macro? What, if any, problems can I expect from protobufs with no thread safety. I have some apprehensions about it and it would be great if someone could clarify those for me:-

1. Is the thread safety only an issue during compilation of .proto files to java/c++ source files? or does protobuf also rely on thread safety during execution of compiled code?

Protobuf uses mutex/locks at runtime to protect certain data structures in multi-threading environment.

 

2. If I dont use thread safety, does protobuf gracefully fall back to single threaded model where needed, or still try to use threads but in somewhat "unsafe" fashion which can lead to bugs such as deadlocks if im unlucky?

Protobuf doesn't create threads, but with no_thread_safety macro, all mutex/locks will be turned into nop. That means you can only use protobuf in a single threaded binary. If you try to use messages in multiple threads, the code may break unexpectedly.

 

3. How is the performance affected while using thread unsafe code? if anyone has done some benchmarking, would be good to see the results.

Regards,

Safi

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+u...@googlegroups.com.
To post to this group, send email to prot...@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/groups/opt_out.

[Safi Ali]

Hi,

Thanks a lot Feng for your quick answer. Well at the moment, we are only planning to use it in a single threaded application where we write/read messages sequentially, instead of in parallel. So I guess we are safe for now.

Regards,

Safi

[Igor Gatis]

I'm using -DGOOGLE_PROTOBUF_NO_THREAD_SAFETY but I'm hitting the following errors:

"src/google/protobuf/stubs/atomic_sequence_num.h", line 43: Error:  #20: identifier "AtomicWord" is undefined

    AtomicWord GetNext() {

    ^

"src/google/protobuf/stubs/atomic_sequence_num.h", line 47: Error:  #20: identifier "AtomicWord" is undefined

    AtomicWord word_;

    ^

"src/google/protobuf/stubs/atomic_sequence_num.h", line 44: Error:  #20: identifier "NoBarrier_AtomicIncrement" is undefined

      return NoBarrier_AtomicIncrement(&word_, 1) - 1;

Any chance there is a GOOGLE_PROTOBUF_NO_THREAD_SAFETY check missing?

[Brad Larson]

On Tuesday, July 19, 2016 at 10:15:29 AM UTC-5, Igor Gatis wrote:

I'm using -DGOOGLE_PROTOBUF_NO_THREAD_SAFETY but I'm hitting the following errors:

"src/google/protobuf/stubs/atomic_sequence_num.h", line 43: Error:  #20: identifier "AtomicWord" is undefined

    AtomicWord GetNext() {

    ^

"src/google/protobuf/stubs/atomic_sequence_num.h", line 47: Error:  #20: identifier "AtomicWord" is undefined

    AtomicWord word_;

    ^

"src/google/protobuf/stubs/atomic_sequence_num.h", line 44: Error:  #20: identifier "NoBarrier_AtomicIncrement" is undefined

      return NoBarrier_AtomicIncrement(&word_, 1) - 1;

Any chance there is a GOOGLE_PROTOBUF_NO_THREAD_SAFETY check missing?

I see these errors as well.

 

On Monday, October 21, 2013 at 2:16:20 PM UTC-3, Safi Ali wrote:

Hi,

Thanks a lot Feng for your quick answer. Well at the moment, we are only planning to use it in a single threaded application where we write/read messages sequentially, instead of in parallel. So I guess we are safe for now.

Regards,

Safi

On Monday, October 21, 2013 7:32:19 PM UTC+3, Feng Xiao wrote:

On Mon, Oct 21, 2013 at 1:05 AM, Safi Ali <safi...@gmail.com> wrote:

Hi,

I have been trying to compile google protocol buffers 2.5.0 on solaris (sparc) environment. It seems I have to use the GOOGLE_PROTOBUF_NO_THREAD_SAFETY macro in order to make it compile properly. So I follow these steps to compile protobuf:-

./configure CPPFLAGS="-DGOOGLE_PROTOBUF_NO_THREAD_SAFETY"

make 

make check

In 'make check', all tests pass. 

Can anyone shed some light on what are the caveats of using the no_thread_safety macro? What, if any, problems can I expect from protobufs with no thread safety. I have some apprehensions about it and it would be great if someone could clarify those for me:-

1. Is the thread safety only an issue during compilation of .proto files to java/c++ source files? or does protobuf also rely on thread safety during execution of compiled code?

Protobuf uses mutex/locks at runtime to protect certain data structures in multi-threading environment.

 

2. If I dont use thread safety, does protobuf gracefully fall back to single threaded model where needed, or still try to use threads but in somewhat "unsafe" fashion which can lead to bugs such as deadlocks if im unlucky?

Protobuf doesn't create threads, but with no_thread_safety macro, all mutex/locks will be turned into nop. That means you can only use protobuf in a single threaded binary. If you try to use messages in multiple threads, the code may break unexpectedly.

Can anyone confirm, is it acceptable to read/write different messages in different threads?  Or can we only have one thread make any protobuf calls at all?

[Feng Xiao]

If you are using GOOGLE_PROTOBUF_NO_THREAD_SAFETY, you cannot use protobuf in multiple threads. Even using different message types in different threads will be problematic because all message types share the same global DescriptorPool/MessageFactory/etc. 

If you are not using GOOGLE_PROTOBUF_NO_THREAD_SAFETY, protobuf supports the same thread-safety semantics as with standard types. Reading/writing different messages in different threads are fine. Reading the same message in multiple threads is also fine. To write a message in multiple threads a lock must be used.

 

 

 

3. How is the performance affected while using thread unsafe code? if anyone has done some benchmarking, would be good to see the results.

Regards,

Safi

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+u...@googlegroups.com.
To post to this group, send email to prot...@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+unsubscribe@googlegroups.com.

To post to this group, send email to prot...@googlegroups.com.

Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[Brad Larson]

Thank you Feng, this is very helpful.

I started trying to get things to compile with GOOGLE_PROTOBUF_NO_THREAD_SAFETY, but ran into some difficulties with the deterministic serialization feature that require atomics that are a little over my head, so for now I'll go back to supporting threads.  Hopefully someone with more knowledge on this feature can come along and fix the no thread support, as it is very desirable on embedded / non-pthread platforms like mine.

 

 

 

 

3. How is the performance affected while using thread unsafe code? if anyone has done some benchmarking, would be good to see the results.

Regards,

Safi

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+u...@googlegroups.com.
To post to this group, send email to prot...@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+u...@googlegroups.com.
To post to this group, send email to prot...@googlegroups.com.