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_i nit(&plock, NULL); }
~Lock() {}
void lock() { pthread_mutex_l ock(&plock); }
void unlock() { pthread_mutex_u nlock(&plock); }

private:
pthread_mutex_t plock;
};

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

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

[Victor Bazarov]

Re: mutex for c++

"Bill Chiu" <billchiu@despa mmed.com> wrote...[color=blue]
> 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_i nit(&plock, NULL); }
> ~Lock() {}[/color]

I've always wondered, shouldn't such lock be released upon destruction?
[color=blue]
> void lock() { pthread_mutex_l ock(&plock); }
> void unlock() { pthread_mutex_u nlock(&plock); }
>
> private:
> pthread_mutex_t plock;
> };
>
> class testdriver {
> testdriver();
> private:
> Lock testlock;
> }[/color]
;

And what this testdriver supposed to accomplish? It cannot be
instantiated (private constructor), neither does it lock or
unlock its testlock...
[color=blue]
> testdriver::tes tdriver() {
> }
>
> p.s. I don't want to use boost lib either.[/color]

Maybe you should. At least they debug it.

Victor

[Bill Chiu]

Re: mutex for c++

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_i nit(&plock, NULL); }
~Lock() { pthread_mutex_u nlock(&plock); }

void lock() { pthread_mutex_l ock(&plock); }
void unlock() { pthread_mutex_u nlock(&plock); }

private:
pthread_mutex_t plock;
};

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

Bill


"Victor Bazarov" <v.Abazarov@com Acast.net> wrote in message news:<RMuob.694 14$HS4.623219@a ttbi_s01>...[color=blue]
> "Bill Chiu" <billchiu@despa mmed.com> wrote...[color=green]
> > 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_i nit(&plock, NULL); }
> > ~Lock() {}[/color]
>
> I've always wondered, shouldn't such lock be released upon destruction?
>[color=green]
> > void lock() { pthread_mutex_l ock(&plock); }
> > void unlock() { pthread_mutex_u nlock(&plock); }
> >
> > private:
> > pthread_mutex_t plock;
> > };
> >
> > class testdriver {
> > testdriver();
> > private:
> > Lock testlock;
> > }[/color]
> ;
>
> And what this testdriver supposed to accomplish? It cannot be
> instantiated (private constructor), neither does it lock or
> unlock its testlock...
>[color=green]
> > testdriver::tes tdriver() {
> > }
> >
> > p.s. I don't want to use boost lib either.[/color]
>
> Maybe you should. At least they debug it.
>
> Victor[/color]

[SenderX]

Re: mutex for c++

> Yeah I guess I forgot to release the lock on destructor and public the[color=blue]
> constructor on that last one.. is this new code below good
> wrapper/impl of lock?[/color]

no.

This is:

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

Go to the mutex.h link.

--
The designer of the experimental, SMP and HyperThread friendly, AppCore
library.

http://AppCore.home.comcast.net

[Alexander Terekhov]

Re: mutex for c++


SenderX wrote:[color=blue]
>[color=green]
> > 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?[/color]
>
> no.
>
> This is:
>
> http://appcore.home.comcast.net/pthreads/mutex.h
>
> Go to the mutex.h link.[/color]

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_MUTE X_FOR_WINDOWS_I NITIALIZER { 0, 0 }

class swap_based_mute x_for_windows {

/* ... */

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

/* ... */

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

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

bool timedlock(absol ute_timeout const & timeout) {
return m_lock_status.s wap(0, msync::acq) >= 0 ?
slow_timedlock( timeout) : true;
}

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

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

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

bool slow_timedlock( absolute_timeou t const & timeout) {
auto_reset_even t & retry_event = DCSI();
while (m_lock_status. swap(1, msync::acq) >= 0)
if (!retry_event.t imedwait(timeou t)) return false;
return true;
}

auto_reset_even t & DCSI() {
auto_reset_even t * retry_event;
if ((retry_event = m_retry_event.l oad(msync::none )) == 0) {
named_windows_m utex_trick guard(this);
if ((retry_event = m_retry_event.l oad(msync::none )) == 0) {
retry_event = new auto_reset_even t()
m_retry_event.s tore(retry_even t, msync::rel);
m_lock_status.s tore(-1, msync::rel);
}
}
return *retry_event;
}

};

regards,
alexander.

--
typedef std::aligned_st orage<std::mute x> pthread_mutex_t ; // POD
extern "C" int pthread_mutex_d estroy(pthread_ mutex_t * m) throw() {
m->object().~mute x();
return 0;
}

[Markus Elfring]

Re: mutex for c++

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]

Re: mutex for c++

> I wrap pthread lock with a C++ class, and it caused crashes... Is the[color=blue]
> below implementation a real baddy and needs serious spanking??[/color]
....[color=blue]
> p.s. I don't want to use boost lib either.[/color]

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=80abeffb0b0261bb&seekm=_3Gib.2217%24mM1.1237%40newsfep4-winn.server.ntli.net&group=comp.programming.threads

If you do not like the Boost library, try these implementations :
- http://pmade.org/software/safept/dow...x_1_1Lock.html
- http://zthread.sourceforge.net/html/..._1_1Mutex.html

[Markus Elfring]

Re: mutex for c++

one more library:
MutexLock Class Reference

http://www.gnu.org/software/commoncpp/docs/refman/html/class_mutex_lock.html