Modify

Ticket #3269 (closed Bugs: fixed)

Opened 5 years ago

Last modified 4 years ago

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

Reported by: anonymous Owned by: anthonyw
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

Change History

comment:1 Changed 5 years ago by talanchor@…

  • Owner set to anthonyw
  • Component changed from None to thread

comment:2 follow-up: ↓ 3 Changed 5 years ago by steven_watanabe

What errors do you expect from pthread_mutex_lock?

comment:3 in reply to: ↑ 2 Changed 5 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 follow-up: ↓ 5 Changed 5 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 5 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 5 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 5 years ago by anonymous

  • Version changed from Boost 1.39.0 to Boost 1.40.0
  • Milestone changed from Boost 1.40.0 to Boost 1.41.0

comment:8 Changed 4 years ago by anonymous

  • Version changed from Boost 1.40.0 to Boost 1.43.0
  • Milestone changed from Boost 1.41.0 to Boost 1.43.0

comment:9 Changed 4 years ago by viboes

I propose to resolve as invalid as works as designed.

comment:10 Changed 4 years ago by anthonyw

  • Status changed from new to closed
  • Resolution set to fixed

Fixed on trunk

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


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

 
Note: See TracTickets for help on using tickets.