mutex for c++

[Bill Chiu]

Dear C++ Universe,

I wrap pthread lock with a C++ class, and it caused crashes.. Is the
below implementation a real baddy and needs serious spanking??

#include <pthread.h>
class Lock {
public:
Lock() { pthread_mutex_init(&plock, NULL); }
~Lock() {}
void lock() { pthread_mutex_lock(&plock); }
void unlock() { pthread_mutex_unlock(&plock); }

private:
pthread_mutex_t plock;
};

class testdriver {
testdriver();
private:
Lock testlock;
}
testdriver::testdriver() {
}

p.s. I don't want to use boost lib either.

 

[Victor Bazarov]

Dear C++ Universe,

I wrap pthread lock with a C++ class, and it caused crashes.. Is the
below implementation a real baddy and needs serious spanking??

#include <pthread.h>
class Lock {
public:
Lock() { pthread_mutex_init(&plock, NULL); }
~Lock() {}

I've always wondered, shouldn't such lock be released upon destruction?

void lock() { pthread_mutex_lock(&plock); }
void unlock() { pthread_mutex_unlock(&plock); }

private:
pthread_mutex_t plock;
};

class testdriver {
testdriver();
private:
Lock testlock;
}

;

And what this testdriver supposed to accomplish? It cannot be
instantiated (private constructor), neither does it lock or
unlock its testlock...

testdriver::testdriver() {
}

p.s. I don't want to use boost lib either.

Maybe you should. At least they debug it.

Victor

 

[Bill Chiu]

Hey,

Yeah I guess I forgot to release the lock on destructor and public the
constructor on that last one.. is this new code below good
wrapper/impl of lock? I worry extra code added by c++ (if any) is not
thread safe... comments?

#include <pthread.h>

class Lock {
public:
Lock() { pthread_mutex_init(&plock, NULL); }
~Lock() { pthread_mutex_unlock(&plock); }

void lock() { pthread_mutex_lock(&plock); }
void unlock() { pthread_mutex_unlock(&plock); }

private:
pthread_mutex_t plock;
};

class testdriver {
public:
testdriver();
private:
Lock testlock; // create a lock
}

Bill

 

[SenderX]

Yeah I guess I forgot to release the lock on destructor and public the

constructor on that last one.. is this new code below good
wrapper/impl of lock?

no.

This is:

http://appcore.home.comcast.net/pthreads/mutex.h

Go to the mutex.h link.

 

[Alexander Terekhov]

no.

This is:

http://appcore.home.comcast.net/pthreads/mutex.h

Go to the mutex.h link.

This was just an illustration. It doesn't properly report resource-not-
available errors. Mutex constructor can throw std::bad_alloc, to begin
with (std::try_again and std::no_way aside for a moment ;-) ). As for
the lock acquisition... since lock initialization can be done in "a
lazy fashion", the same applies for the initial calls done by threads;
"in general", so to speak. Here is an illustration to clarify it.

#define SWAP_BASED_MUTEX_FOR_WINDOWS_INITIALIZER { 0, 0 }

class swap_based_mutex_for_windows {

/* ... */

// -1: free, 0: locked, 1: contention
atomic<int> m_lock_status;
atomic<auto_reset_event *> m_retry_event;

/* ... */

void lock() {
if (m_lock_status.swap(0, msync::acq) >= 0)
slow_lock();
}

bool trylock() {
return m_lock_status.swap(0, msync::acq) >= 0 ?
slow_trylock() : true;
}

bool timedlock(absolute_timeout const & timeout) {
return m_lock_status.swap(0, msync::acq) >= 0 ?
slow_timedlock(timeout) : true;
}

void unlock() {
if (m_lock_status.swap(-1, msync::rel) > 0)
m_retry_event.load(msync::none)->set();
}

void slow_lock() {
auto_reset_event & retry_event = DCSI();
while (m_lock_status.swap(1, msync::acq) >= 0)
retry_event.wait();
}

bool slow_trylock() {
DCSI();
return m_lock_status.swap(1, msync::acq) < 0;
}

bool slow_timedlock(absolute_timeout const & timeout) {
auto_reset_event & retry_event = DCSI();
while (m_lock_status.swap(1, msync::acq) >= 0)
if (!retry_event.timedwait(timeout)) return false;
return true;
}

auto_reset_event & DCSI() {
auto_reset_event * retry_event;
if ((retry_event = m_retry_event.load(msync::none)) == 0) {
named_windows_mutex_trick guard(this);
if ((retry_event = m_retry_event.load(msync::none)) == 0) {
retry_event = new auto_reset_event()
m_retry_event.store(retry_event, msync::rel);
m_lock_status.store(-1, msync::rel);
}
}
return *retry_event;
}

};

regards,
alexander.

--
typedef std::aligned_storage<std::mutex> pthread_mutex_t; // POD
extern "C" int pthread_mutex_destroy(pthread_mutex_t * m) throw() {
m->object().~mutex();
return 0;
}

 

[Markus Elfring]

I suggest to read the following documents to correct your locking
class.

1. Boost.Threads - Mutex Concept
http://boost.org/libs/thread/doc/mutex_concept.html

2. Resource acquisition is initialization
http://c2.com/cgi/wiki?ResourceAcquisitionIsInitialization

3. Scoped Locking
Synchronized Block, Guard, Execute-Around Object
http://www.dpunkt.de/leseproben/3-89864-142-2/Scoped-Locking-Pattern.pdf
(German)
übersetztes Buch "Pattern-orientierte Software-Architektur: Muster
für nebenläufige und vernetzte Objekte", ISBN 3-89864-142-2
original book "Pattern-Oriented Software Architecture. Volume 2:
Patterns for Concurrent and Networked Objects", John Wiley & Sons Ltd.

4. Double-Checked Locking
http://patterndigest.com/patterns/DoubleCheckedLocking.html

 

[Markus Elfring]

I wrap pthread lock with a C++ class, and it caused crashes... Is the

below implementation a real baddy and needs serious spanking?? ....
p.s. I don't want to use boost lib either.

You can avoid to repeat some design mistakes if you choose and use one
of the existing class libraries. Please look at discussions on the
topic "C++ threads".
http://groups.google.de/groups?th=8...erver.ntli.net&group=comp.programming.threads

If you do not like the Boost library, try these implementations:
- http://pmade.org/software/safept/download/documentation/doxygen/classSafePt_1_1Mutex_1_1Lock.html
- http://zthread.sourceforge.net/html/classZThread_1_1Mutex.html

 

[Markus Elfring]

one more library:
MutexLock Class Reference
http://www.gnu.org/software/commoncpp/docs/refman/html/class_mutex_lock.html