[boost] Re: [boost::thread] locks, exceptions and assertions

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2003-07-18 03:23:50

Russell Hind wrote:
> This has probably been discussed before (most things to do with the 
> thread library have been) but I'll ask anyway:
> 
> Why does scoped_lock (and possibly the other lock) throw exceptions if 
> they are already locked upon calling lock?
> 
>     void lock()
>     {
>         if (m_locked) throw lock_error();
>         lock_ops<Mutex>::lock(m_mutex);
>         m_locked = true;
>     }
>     void unlock()
>     {
>         if (!m_locked) throw lock_error();
>         lock_ops<Mutex>::unlock(m_mutex);
>         m_locked = false;
>     }
> 
> Surely if they are already locked, then this is a logic error on the 
> code side.  I understand that mutex contructors and stuff throw if they 
> can't allocate the resources from the OS, as the code couldn't ensure 
> that would succeed, but if I call lock on an already locked scoped_lock, 
> then isn't that a coding error that could be caught with an assert 
> rather than an exception?

I think that's not specific to locks/threads. In general, a library 
should *never* contain assert/exit/abort or anything else which stops 
the execution of a process immediately. An exception leaves the choice 
of how to react to the user - the library IMHO can't make a good 
decision as it doesn't know the context in which it is used.

Consider a process serving HTTP queries. When processing a query, it is 
protected by try/catch and almost every error is caught, written to the 
log-file and the process keeps running and serving other queries. 
Perfectly reasonable IMO, actually it's the design we are running here 
in our company :)

Regards, Daniel

-- 
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: [phone], fax: [phone]
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de