Re: Double checked locking pattern article on aristeia
"Mathias Gaunard" <loufoque@gmail.com> wrote in message
news:0f960bb1-ebad-4dc6-9b33-17d9e701946c@h5g2000vbf.googlegroups.com...
On Oct 24, 6:46 pm, Alexander Terekhov <terek...@web.de> wrote:
I always thought that C++11 mutex locks can be expressed in terms of
relaxed C++11 atomic<> operations and acquire/release fences (not the
same as memory_order_seq_cst fence).
AFAIK, locking a mutex is a full barrier, not just an acquire barrier.
This is not the case for spinlocks though.
Sure, you can do a a full barrier by doing an acquire followed by a
release, but it's possibly more efficient to just do the full barrier.
class swap_based_mutex_for_windows { // noncopyable
atomic<int> m_lock_status; // 0: free, 1/-1: locked/contention
auto_reset_event m_retry_event; // slow binary semaphore (windows)
How is that pseudo-code written only using built-in atomic operations
when there is a reference to a heavyweight kernel-level
synchronization mechanism?
Perhaps something like:
<sorry for any typos!>
_____________________________________________
struct auto_reset_event
{
std::mutex m_mutex;
std::condition_variable m_cond;
bool m_state;
auto_reset_event() : m_state(false) {}
auto_reset_event(bool state) : m_state(state) {}
void set()
{
m_mutex.lock();
m_state = true;
lock.unlock();
m_cond.notify_one();
}
void wait()
{
std::unique_lock<std::mutex> lock(m_mutex);
while (! m_state) m_cond.wait(lock);
m_state = false;
}
};
_____________________________________________
;^)
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]