standard atomic read bool exist?

[Christopher]

Does there exist a standard way to atomically read the value of a
bool?

class MultithreadedFoo()
{
bool m_value;

protected:
const bool SafelyReadValue() const
{
// What goes here to prevent the need for locks
// If multiple threads may reach this point?
}
};

 

[red floyd]

Does there exist a standard way to atomically read the value of a
bool?

class MultithreadedFoo()
{
bool m_value;

protected:
const bool SafelyReadValue() const
{
// What goes here to prevent the need for locks
// If multiple threads may reach this point?
}
};

Not in the current standard. Threading is not part of ISO/IEC
14882:2003, you have to do something platform specific.

I *THINK* that threading is incorporated into the 2009 draft Standard,
though, so in the future there may be a way. DISCLAIMER: I could be
wrong about the draft.

 

[REH]

Does there exist a standard way to atomically read the value of a
bool?

class MultithreadedFoo()
{
bool m_value;

protected:
const bool SafelyReadValue() const
{
// What goes here to prevent the need for locks
// If multiple threads may reach this point?
}

};

class MultithreadedFoo()
{
sig_atomic_t m_value;

protected:
bool SafelyReadValue() const
{
return m_value != 0;
}

};

 

[Phil Endecott]

Does there exist a standard way to atomically read the value of a
bool?

Not a standard way, no.

class MultithreadedFoo()
{
bool m_value;

protected:
const bool SafelyReadValue() const
{
// What goes here to prevent the need for locks
// If multiple threads may reach this point?
}
};

I'm not aware of any common hardware platforms where you can't simply
read the bool normally, as it's small enough that the read is atomic on
the bus. There are plenty of other things to worry about though, e.g.
the compiler or the hardware re-ordering the access to the bool amongst
the other operations, the compiler optimising it away, etc.

Phil.

 

[James Kanze]

class MultithreadedFoo()
{
sig_atomic_t m_value;

protected:
bool SafelyReadValue() const
{
return m_value != 0;
}
};

sig_atomic_t makes no guarantees with regards to threading. In
particular, a signal will execute within the same thread of
execution---and so on the same CPU core; another thread might
not.

Some sort of synchronization is necessary if you want to be sure
that other threads see the modification. At least in theory.
In practice, of course, such flags are useless unless other data
in also involved, and you definitely need synchronization in
order to ensure the correct ordering of the writes and reads.

The simplest solution is to protect all accesses to the bool
with a mutex (pthread_mutex_t, CriticalSection---badly misnamed,
that one, etc.---or boost::mutex and a scoped_lock). *All*
access, not just the write.

 

[James Kanze]

Not a standard way, no.

I'm not aware of any common hardware platforms where you can't
simply read the bool normally, as it's small enough that the
read is atomic on the bus.

I think you're playing on words. When people ask about atomic
access, they generally mean that one thread can write, and
another can read, without problems. Possible splitting (half of
the value being written, then the other thread reading the
entire value, then the other half being written) is almost
certainly not a problem here, but all of the other usual
synchronization concerns are.

There are plenty of other things to worry about though, e.g.
the compiler or the hardware re-ordering the access to the
bool amongst the other operations, the compiler optimising it
away, etc.

Exactly. Some form of external synchronization is necessary, or
undefined behavior occurs. (According to Posix, I think
Windows, and the upcoming C++0x.)

 

[Gerry Ford]

I like you, red.

What numbers pre-date 2009 for c++?

 

[REH]

sig_atomic_t makes no guarantees with regards to threading. In
particular, a signal will execute within the same thread of
execution---and so on the same CPU core; another thread might
not.

Some sort of synchronization is necessary if you want to be sure
that other threads see the modification. At least in theory.
In practice, of course, such flags are useless unless other data
in also involved, and you definitely need synchronization in
order to ensure the correct ordering of the writes and reads.

The simplest solution is to protect all accesses to the bool
with a mutex (pthread_mutex_t, CriticalSection---badly misnamed,
that one, etc.---or boost::mutex and a scoped_lock). *All*
access, not just the write.

His only requirement was an ability to read atomically, which
sig_atomic_t provides. He said nothing about requiring mutual
exclusion, or serialized access.

REH

 

[Phil Endecott]

I think you're playing on words. When people ask about atomic
access, they generally mean that one thread can write, and
another can read, without problems.

He specifically asked about reading, and made that clear with a code
example.

Possible splitting (half of
the value being written, then the other thread reading the
entire value, then the other half being written) is almost
certainly not a problem here, but all of the other usual
synchronization concerns are.

Which is exactly what I went on to say:

Exactly. Some form of external synchronization is necessary, or
undefined behavior occurs. (According to Posix, I think
Windows, and the upcoming C++0x.)

Phil.

 

[James Kanze]

His only requirement was an ability to read atomically, which
sig_atomic_t provides. He said nothing about requiring mutual
exclusion, or serialized access.

That's true. If no thread writes the value, he doesn't need any
mutual exclusion.

Of course, if no thread writes the value, I don't see much use
for the code.

 

[James Kanze]

[...]

He specifically asked about reading, and made that clear with a code
example.

Yes, but if no other thread is writing the data, any questions
about atomic access are moot.