[Boost-users] Re: You provide gun, I provide foot.

From: C. Michailidis (dinom_at_[hidden])
Date: 2005-04-09 18:50:38

> do have models. What prevents you from using say, the 
> boost::mutex::scoped_lock model? (Which has the lock/unlock calls.)

Perhaps my initial mailing was too general.  I'll try to state my problem more 
specifically.  The following url, 
http://www.boost.org/libs/thread/example/mutex.cpp , gives an example of how 
mutexes and scoped_locks are typically used.  The counter class shows how an 
atomic counter is implemented.  For completeness I'll copy and paste part of 
the example into my email, here's the class:

class counter
{
public:
    counter() : count(0) { }

    int increment() {
        boost::mutex::scoped_lock scoped_lock(mutex);
        return ++count;
    }

private:
    boost::mutex mutex;
    int count;
};

As I understand it, a thread calling the 'increment' method will be blocked 
until any other thread that has already called 'increment' has returned from 
the method call (more or less).  When the scoped_lock object is instantiated 
its constructor locks the mutex until the scoped_lock goes out of scope (at 
which time the destructor of scoped_lock unlocks the mutex enabling other 
threads to reach the body of increment).  This is all fine and dandy.  My 
problem is that I have an existing COM component which is more similar to:

// please excuse the MSFT parlance
class counter
{
public:
    counter() : count(0) {
       mutex=CreateMutex(NULL, false, NULL);
    }
    void lock() {
       WaitForSingleObject(mutex, INFINITE);
    }
    int increment() {
        return ++count;
    }
    void unlock {
        ReleaseMutex(mutex);
    }
    ~counter() {
        CloseHandle(mutex);
    }

private:
    unsigned long mutex;
    int count;
};

When using the COM component the caller is required to call 'lock' before 
calling any other methods (in this case 'increment'), when you are finished 
using the component you must call 'unlock'.

So... here's my problem, how can I use Boost.Threads to create the same kind 
of functionality without changing my COM interfaces?  Remember that this is 
just for illustration so my sample code may need changes before compiling ;-)

In any case, the actual component is more sophisticated than the simple 
example I gave, and could actually be called from a language other than C++ 
(e.g. Visual Basic).  AFAIK boost mutexes must be locked using scoped_locks 
and it would seem that they aren't appropriate for my situation.  I can 
certainly appreciate the benefits of scoped_locks (esp. in a homogeneous 
environment where all code is written in C++).  It just seems silly to force 
the user to use ONLY scoped_locks when in some situations the additional 
requirements they have make them unusable.  Sure, most of the time the mutex 
should be unlocked at the end of the block... however when the critical 
section is composed of code written in more than one language or in a more 
dynamic algorithm it may easier to unlock it elsewhere, no?

Perhaps this is an issue more appropriate for the boost-devel list... but, if 
there really isn't a way to simply lock/unlock a mutex I think it is awefully 
rude and arrogant of the developers considering the fact that more 
straight-forward multi-threaded IPC mechanisms have been around for quite 
some time and programmers have been able to use them effectively without much 
trouble.  It's my opinion that a great toolkit not only provides robust and 
sophisticated facilities but *ALSO* gives the developer enough 'rope to hang 
themselves'.  After all, isn't the freedom to shoot yourself in the foot one 
of the major advantages of writing code in C/C++?

I use the Boost library not only to add functionality to my software but to 
act as a common API in cross-platform environments.  Nearly every modern API 
supports some kind of fundamental lock/unlock mechanism for mutexes, why 
shouldn't boost?  And yes, to answer one of the replys... I am not being 
forced to use boost, in this case it seems as though I can't!  It would be 
nice however, since I'm using other Boost modules in the project.

In summary, since "Lock concepts are the only way to lock and unlock a mutex 
object: lock and unlock functions are not exposed by any Boost.Threads mutex 
objects", it seems as though I'm left out in the cold!

Any suggestions?
Any boost developers reading this?
Anyone feel my pain?
Am I just being blindly stubborn?

LOL,
Dino