> Behalf Of Batov, Vladimir
>
> > bool foo(bool threadsafe)
> > {
> > mutex::scoped_lock l(m, !threadsafe);
> > }
>
> I am not sure if the example above is appropriate and indicative of
the
> problem we are trying to solve. Thread-safety should not be a run-time
> configurable property. Like we do not decide on the fly (at run-time)
if
> our ref.-counting class is to be thread-safe or not. All that is
> resolved at compile time.
>" Thread-safety should not be a run-time configurable property."
I think this is somewhat incorrect as absolutes usually are. I
currently have a design where I use both an interface that supports
locking and an interface which does not. It is an important feature of
the design. Using such a run time parameter is not my choice because I
am especially sensitive to performance but it might be a better design
for others given other requirements.
Non-locking versions are also useful when you want to combine
operations. Take a lock, do stuff, and then release lock. Repeatedly
locking has deficiencies which may or may not matter to you.
$0.005,
Matt Hurd.
FWIW I wrap boost mutexex and locks in my own policy-like stuff. E.g:
___________________________________________________________
struct shareable
{
protected:
struct adapted_mutex : public boost::rw_mutex
{
adapted_mutex(
lock_priority::type lp = lock_priority::exclusive
)
: rw_mutex( convert( lp) ) {}
~adapted_mutex() {}
};
struct adapted_try_mutex : public boost::try_rw_mutex
{
adapted_try_mutex(
lock_priority::type lp = lock_priority::exclusive
)
: try_rw_mutex( convert( lp) ) {}
~adapted_try_mutex() {}
};
struct adapted_timed_mutex : public boost::timed_rw_mutex
{
adapted_timed_mutex(
lock_priority::type lp = lock_priority::exclusive
)
: timed_rw_mutex( convert( lp) ) {}
~adapted_timed_mutex() {}
};
public:
typedef adapted_mutex mutex;
typedef adapted_try_mutex try_mutex;
typedef adapted_timed_mutex timed_mutex;
typedef shareable_lock<mutex> lock;
typedef shareable_lock<try_mutex> try_lock;
typedef shareable_lock<timed_mutex> timed_lock;
typedef atomic_op_interlocked atomic_op;
};
___________________________________________________________
So I can parameterise classes with a synch policy.
(Less than ideal but I haven't got around to making it nicer yet.)
For the interface where I need to support single threaded and
multi-threaded usage of the same object ( as opposed to type ) I use
this approach...
___________________________________________________________
template
<
class S = synch::shareable
>
class instrument : public synch::monitor<S>
{
SYNCH_SIMPLE_ATTRIBUTE( susquehanna_code, std::string );
SYNCH_SIMPLE_ATTRIBUTE( exchange_code, std::string );
SYNCH_SIMPLE_ATTRIBUTE( underlying, std::string );
SYNCH_SIMPLE_ATTRIBUTE( bid, double );
SYNCH_SIMPLE_ATTRIBUTE( bid_volume, double );
SYNCH_SIMPLE_ATTRIBUTE( ask, double );
SYNCH_SIMPLE_ATTRIBUTE( ask_volume, double );
SYNCH_SIMPLE_ATTRIBUTE( last, double );
SYNCH_SIMPLE_ATTRIBUTE( last_volume, double );
SYNCH_SIMPLE_ATTRIBUTE( prior_settlement, double );
};
___________________________________________________________
This way I can use an object in the following manner:
___________________________________________________________
te::instrument<> i_sample;
i_sample.exchange_code<true>("hello"); // locking
{
te::instrument<>::lock lk( i_sample.guard() );
i_sample.exchange_code<false>("hello"); // non-locking
}
i_sample.exchange_code("hello"); // locking
std::string hello = i_sample.exchange_code(); // locking
hello = i_sample.exchange_code<false>(); // non-locking
hello = i_sample.exchange_code<true>(); // locking
hello = i_sample.exchange_code_ref(); // non-locking by nature
___________________________________________________________
I could also specify
te::instrument< synch::no_synch > // locking is elided
te::instrument< synch::simple > // exclusive locking
te::instrument< synch::no_synch > // allows recursive
locking
te::instrument< synch::shareable > // allows shared or
exclusive locks (think r/w)
The interface to the non-locking version is still valid. User must code
to shareable concept for everything to work for all concepts.
Where SYNCH_SIMPLE_ATTRIBUTE defines a bunch of simple attribute
helpers and looks like:
#define SYNCH_SIMPLE_ATTRIBUTE( VAR_NAME, VAR_TYPE )
\
\
public:
\
template< bool >
\
void
\
VAR_NAME
\
(
\
boost::call_traits< VAR_TYPE >::param_type new_ ## VAR_NAME
\
)
\
{
\
if ( boost::needs_lock<VAR_TYPE>::value ) {
\
lock lk(guard_ );
\
VAR_NAME<false>( new_ ## VAR_NAME);
\
} else {
\
VAR_NAME<false>( new_ ## VAR_NAME);
\
}
\
}
\
\
void
\
VAR_NAME
\
(
\
boost::call_traits< VAR_TYPE >::param_type new_ ## VAR_NAME
\
)
\
{
\
VAR_NAME < true > ( new_ ## VAR_NAME );
\
}
\
\
template< >
\
void
\
VAR_NAME<false>
\
(
\
boost::call_traits<VAR_TYPE>::param_type new_ ## VAR_NAME
\
)
\
{
\
VAR_NAME ## _ = new_ ## VAR_NAME;
\
}
\
\
template< bool >
\
VAR_TYPE
\
VAR_NAME( ) const
\
{
\
if ( boost::needs_lock< VAR_TYPE >::value ) {
\
lock lk(guard_, synch::lock_status::shared );
\
return VAR_NAME<false>( );
\
} else {
\
return VAR_NAME<false>( );
\
}
\
}
\
\
VAR_TYPE
\
VAR_NAME( ) const
\
{
\
return VAR_NAME<true>( );
\
}
\
\
template< >
\
VAR_TYPE
\
VAR_NAME <false>() const
\
{
\
return VAR_NAME ## _;
\
}
\
\
boost::call_traits<VAR_TYPE>::const_reference
\
VAR_NAME ## _ref( ) const
\
{
\
return VAR_NAME ## _;
\
}
\
\
private:
\
VAR_TYPE VAR_NAME ## _;
\
SYNCH_SIMPLE_ATTRIBUTE includes an extra thing
boost::needs_lock<VAR_TYPE>::value
that checks if the size of the type is > pointer size which means, for
Intel & AMD, that locking is not required as the assignment of aligned
types is atomic.
Copy constructors, assignment and cloning are further issues ;-)
IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
