On Fri, Jul 7, 2017 at 1:28 PM, Brad Larson <[email protected]> wrote:
>
>
> 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 <[email protected]> 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?
>
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 [email protected].
>>>>> To post to this group, send email to [email protected].
>>>>> 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 [email protected].
> To post to this group, send email to [email protected].
> Visit this group at https://groups.google.com/group/protobuf.
> For more options, visit https://groups.google.com/d/optout.
>
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
