"rh" <rhashemian@hotmail.com> wrote in message
news:56c3b705.0407301217.6c584e61@posting.google.com...
> hi all,
> this is what the clr docs say about boolean:
>
> This type is safe for multithreaded operations
>
>
> does this mean i can access a bool object from any thread
> without worrying about sync issues? pretty sure that's it,
> but just wanna make 100% sure.
>
> thanks,
> rh

"Valery Pryamikov" <Valery@nospam.harper.no> wrote in message
news:%23l8SSmndEHA.2908@TK2MSFTNGP10.phx.gbl...
> Hi,
> it only means that reads and writes are atomic. However, there are no
> guarantee from rearranging memory access and similar. I.e. if you are
using
> it independently (in isolation) from the rest of your variables - you will
> be 100% safe, but this is kind of ...unrealistic...
>
> -Valery.
> http://www.harper.no/valery
>
> "rh" <rhashemian@hotmail.com> wrote in message
> news:56c3b705.0407301217.6c584e61@posting.google.com...
> > hi all,
> > this is what the clr docs say about boolean:
> >
> > This type is safe for multithreaded operations
> >
> >
> > does this mean i can access a bool object from any thread
> > without worrying about sync issues? pretty sure that's it,
> > but just wanna make 100% sure.
> >
> > thanks,
> > rh
>
>

"Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message
news:MPG.1b75e43047507f4398b04c@msnews.microsoft.com...
> Christopher Wells <christopher_wells@invalid.invalid> wrote:
> > For example, it's safe to have code like this:
> >
> > <snip>
>
> No it's not. There's nothing to force the worker thread to "see" the
> new value of m_thread_must_exit unless there's a "write" memory barrier
> in the writing thread and a "read" memory barrier.

> In practice it's unlikely to cause any problems with the current
> implementation on current processors, but I always try to code to the
> spec rather than to the current implementation.

Christopher Wells <christopher_wells@invalid.invalid> wrote:
> For example, it's safe to have code like this:
>
> class C
> {
> bool m_thread_must_exit = false;
> public C()
> {
> //start a worker thread which runs the thread_procedure
> }
> void thread_procedure()
> {
> while (!m_thread_must_exit)
> {
> //...do thread work...
> }
> }
> public void stop_the_thread()
> {
> //following operation is safe
> //even though this thread is writing to bool m_thread_must_exit
> //while the worker thread is reading from bool m_thread_must_exit
>
> //tell the worker thread to exit
> m_thread_must_exit = true;
> }
> }

Christopher Wells <christopher_wells@invalid.invalid> wrote:
> > No it's not. There's nothing to force the worker thread to "see" the
> > new value of m_thread_must_exit unless there's a "write" memory barrier
> > in the writing thread and a "read" memory barrier.
>
> So I need to declare the variable as volatile.

> > In practice it's unlikely to cause any problems with the current
> > implementation on current processors, but I always try to code to the
> > spec rather than to the current implementation.
>
> FWIW I *have* seen volatile being necessary in release-mode C++ (to prevent
> the variable being enregistered).

"Christopher Wells" <christopher_wells@invalid.invalid> wrote in message
news:uhQRWvxdEHA.3916@TK2MSFTNGP11.phx.gbl...
> For example, it's safe to have code like this:
>
> class C
> {
> bool m_thread_must_exit = false;
> public C()
> {
> //start a worker thread which runs the thread_procedure
> }
> void thread_procedure()
> {
> while (!m_thread_must_exit)
> {
> //...do thread work...
> }
> }
> public void stop_the_thread()
> {
> //following operation is safe
> //even though this thread is writing to bool m_thread_must_exit
> //while the worker thread is reading from bool m_thread_must_exit
>
> //tell the worker thread to exit
> m_thread_must_exit = true;
> }
> }
>
> "Valery Pryamikov" <Valery@nospam.harper.no> wrote in message
> news:%23l8SSmndEHA.2908@TK2MSFTNGP10.phx.gbl...
>> Hi,
>> it only means that reads and writes are atomic. However, there are no
>> guarantee from rearranging memory access and similar. I.e. if you are
> using
>> it independently (in isolation) from the rest of your variables - you
>> will
>> be 100% safe, but this is kind of ...unrealistic...
>>
>> -Valery.
>> http://www.harper.no/valery
>>
>> "rh" <rhashemian@hotmail.com> wrote in message
>> news:56c3b705.0407301217.6c584e61@posting.google.com...
>> > hi all,
>> > this is what the clr docs say about boolean:
>> >
>> > This type is safe for multithreaded operations
>> >
>> >
>> > does this mean i can access a bool object from any thread
>> > without worrying about sync issues? pretty sure that's it,
>> > but just wanna make 100% sure.
>> >
>> > thanks,
>> > rh
>>
>>
>
>

"Valery Pryamikov" <Valery@nospam.harper.no> wrote in message
news:%23tawqm5dEHA.212@TK2MSFTNGP12.phx.gbl...
> Jon already answered this, however I'll just drop my 2c here.
> Depending on cycle body you code may fail in release build regardless of
> used processor architecture.
> For example: read access could be moved out of cycle and that mean that
your
> cycle will never exit on m_thread_must_exit change.

"Christopher Wells" <christopher_wells@invalid.invalid> wrote in message
news:OI0RtdAeEHA.1644@tk2msftngp13.phx.gbl...
>
> "Valery Pryamikov" <Valery@nospam.harper.no> wrote in message
> news:%23tawqm5dEHA.212@TK2MSFTNGP12.phx.gbl...
>> Jon already answered this, however I'll just drop my 2c here.
>> Depending on cycle body you code may fail in release build regardless of
>> used processor architecture.
>> For example: read access could be moved out of cycle and that mean that
> your
>> cycle will never exit on m_thread_must_exit change.
>
> Yeah, volatile is needed.
>
> Still, it *is* an example of where you need thread-safe access to a single
> bool, which is used "independently (in isolation) from the rest of your
> variables" [I'm assuming in my example that the thread procedure may
> access
> other member variables, that are initialized before the thread is started,
> but that the m_thread_must_exit is the only variable that is accessed by
> two
> threads concurrently].
>
>

"Valery Pryamikov" <Valery@nospam.harper.no> wrote in message news:<uhn04JFeEHA.3680@TK2MSFTNGP11.phx.gbl>...
> Not exactly,
> you was using boolean variable for controlling value of instruction pointer
> register that could be considered (and sometimes even called) as program's
> metavariable.
>
> -Valery.
> http://www.harper.no/valery
>
> "Christopher Wells" <christopher_wells@invalid.invalid> wrote in message
> news:OI0RtdAeEHA.1644@tk2msftngp13.phx.gbl...
> >
> > "Valery Pryamikov" <Valery@nospam.harper.no> wrote in message
> > news:%23tawqm5dEHA.212@TK2MSFTNGP12.phx.gbl...
> >> Jon already answered this, however I'll just drop my 2c here.
> >> Depending on cycle body you code may fail in release build regardless of
> >> used processor architecture.
> >> For example: read access could be moved out of cycle and that mean that
> your
> >> cycle will never exit on m_thread_must_exit change.
> >
> > Yeah, volatile is needed.
> >
> > Still, it *is* an example of where you need thread-safe access to a single
> > bool, which is used "independently (in isolation) from the rest of your
> > variables" [I'm assuming in my example that the thread procedure may
> > access
> > other member variables, that are initialized before the thread is started,
> > but that the m_thread_must_exit is the only variable that is accessed by
> > two
> > threads concurrently].
> >