Modify

Opened 8 years ago

Closed 8 years ago

#3269 closed Bugs (fixed)

boost thread - mutex.lock() doesn't throw exception

Reported by: anonymous Owned by: Anthony Williams
Milestone: Boost 1.43.0 Component: thread
Version: Boost 1.43.0 Severity: Problem
Keywords: thread mutex lock Cc:

Description

lock() member function of mutex object doesn't throw any exception on error. There is no error handling capabilities because lock() doesn't return any value.

Attachments (0)

Change History (10)

comment:1 Changed 8 years ago by talanchor@…

Component: Nonethread
Owner: set to Anthony Williams

comment:2 Changed 8 years ago by Steven Watanabe

What errors do you expect from pthread_mutex_lock?

comment:3 in reply to:  2 Changed 8 years ago by anonymous

Replying to steven_watanabe:

What errors do you expect from pthread_mutex_lock?

mutex.lock() call may fail - and it sometimes does (according, for example, to POSIX mutexes), so we need to know that something went wrong. One way to report an error is to throw system_error exception, like for example just::thread library does: http://www.stdthread.co.uk/doc/headers/mutex/mutex/lock.html

comment:4 Changed 8 years ago by Steven Watanabe

Well, it doesn't fail randomly. Most of the possible failures either cannot happen with boost::mutex or are a result of undefined behavior. However, EAGAIN and ENOMEM appear to be possible.

comment:5 in reply to:  4 Changed 8 years ago by anonymous

Replying to steven_watanabe:

Well, it doesn't fail randomly. Most of the possible failures either cannot happen with boost::mutex or are a result of undefined behavior. However, EAGAIN and ENOMEM appear to be possible.

On QNX pthread_mutex_lock may also return EDEADLK - if mutex was not set as recursive, or ETIMEDOUT if "A kernel timeout unblocked the call", and all this return values including EAGAIN are possible. At least this errors should be logged somewhere and execution of the thread should be cancelled.

comment:6 Changed 8 years ago by Steven Watanabe

Relocking a mutex that is already locked by the current thread is undefined behavior, so EDEADLK is irrelevant.

comment:7 Changed 8 years ago by anonymous

Milestone: Boost 1.40.0Boost 1.41.0
Version: Boost 1.39.0Boost 1.40.0

comment:8 Changed 8 years ago by anonymous

Milestone: Boost 1.41.0Boost 1.43.0
Version: Boost 1.40.0Boost 1.43.0

comment:9 Changed 8 years ago by viboes

I propose to resolve as invalid as works as designed.

comment:10 Changed 8 years ago by Anthony Williams

Resolution: fixed
Status: newclosed

Fixed on trunk

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Anthony Williams.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.