Subj : Re: Recursive lock?
To   : comp.programming.threads
From : axter
Date : Thu May 19 2005 11:39 pm

Michel wrote:
> doug wrote:
> > Yeah, we wrap them up.  We do this because we write our code to an
> > 'isolation layer' api.  We then write an isolation layer for each
operating
> > system, mapping the api calls to the primitives supported on that
machine.
> >
> > It's not the fastest way to do it, but it's portable, and in debug
builds we
> > can add in code for things like:
> > - double acquires
> > - invalid frees
> > - high contention (lots of threads waiting for some lock)
> > - long holds (a thread holds a lock for a long time)
> > - hierarchy checking
> >
> > Means we don't have to touch the app code when we port.
> >
>
> Event though I work primarily in win32 land I wrap and isolate all
apis
> as well, for  a lot of the reasons you mention, and to get a
> C++/exception safe interface. Actually i don't see why It would
hamper
> performance or be as fast as native, at least not when diagnostics is

> compiled away. But what typically does the wrapper do on double
acquire
> (assert, throw) and what differences is there in debug and release
builds?
>
> /Michel

FYI:
I'm currently working on a C++ synchronized smart pointer, that allows
thread safe access to an object.
See following link:
http://code.axter.com/sync_ptr.h
http://code.axter.com/sync_ctrl.h

Now, my code is currently using recursive lock, but I plan to change it
to non-recursive by adding a referencing counting object to the RefLock
class.

This should allow any one to use this wrapper class to make an instance
of any object thread safe, by automatically synchronizing access to the
pointer.

If you use a reference counting object, it shouldn't be that hard to
avoid recursive locking by linking the reference counting object with
the mutex.

.