Boost logo

Boost :

From: Rainer Deyke (root_at_[hidden])
Date: 2002-01-31 14:46:00

----- Original Message -----
From: "bill_kempf" <williamkempf_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, January 31, 2002 11:49 AM
Subject: [boost] Re: mutex_traits<>

> Again, the free function approach doesn't discourage usage
> by "newbies". I've seen many MT libraries that expose lock/unlock
> the mutex class's public interface (which is equivalent to free
> functions) as well as providing the Scoped Lock classes for "safer"
> usage. Despite documentation warning of the issues most "newbies"
> invariably call lock/unlock directly instead of using the Scoped
> Lock, and the result is usually buggy programs that seem to run
> during testing but deadlock when software is released. Maybe I'm
> trying to hard, but I want to prevent this newbie mistake while not
> preventing the experts from easily extending the library in ways
> scoped locking causes problems.

Can't the "advanced" mechanisms be implemented in terms of a scoped
lock, i.e.?

  shared_ptr<scoped_lock> shared_access_lock(new scoped_lock);

Or maybe the advanced features could be member fuctions of

  class scoped_lock {
    scoped_lock(mutex&, bool initially_locked = true);
    void lock();
    void unlock();
    bool is_locked() bool;
    ~scoped_lock() { this->unlock(); }

Is it really necessary to expose raw lock/unlock functions at all?

Rainer Deyke | root_at_[hidden] |

Boost list run by bdawes at, gregod at, cpdaniel at, john at