[libcamera-devel] [PATCH] libcamera: base: Make MutexLocker(Mutex &mutex) non-blocking

Laurent Pinchart laurent.pinchart at ideasonboard.com
Fri Apr 29 00:09:12 CEST 2022


Hi Eric,

On Wed, Apr 27, 2022 at 04:26:40PM +0100, Eric Curtin via libcamera-devel wrote:
> Camera::acquire claims to be non-blocking, in order to achieve this,
> std::unique_lock<std::mutex> constructor must be called with
> try_to_lock so it doesn't block if a lock cannot be obtained.
> 
> Bug: https://bugs.libcamera.org/show_bug.cgi?id=127
> Signed-off-by: Eric Curtin <ecurtin at redhat.com>
> ---
>  include/libcamera/base/mutex.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/libcamera/base/mutex.h b/include/libcamera/base/mutex.h
> index 2d23e49e..c4a5f791 100644
> --- a/include/libcamera/base/mutex.h
> +++ b/include/libcamera/base/mutex.h
> @@ -45,7 +45,7 @@ class LIBCAMERA_TSA_SCOPED_CAPABILITY MutexLocker final
>  {
>  public:
>  	explicit MutexLocker(Mutex &mutex) LIBCAMERA_TSA_ACQUIRE(mutex)
> -		: lock_(mutex.mutex_)
> +		: lock_(mutex.mutex_, std::try_to_lock)

With this change, if the mutex is already locked, MutexLocker will
happily continue as if nothing happened. You've certainly made sure
MutexLocker will not block, by effectively disabling all mutexes in
libcamera.

Please look at the backtrace you've posted in bug 127, and check why
std::mutex::lock() blocks indefinitely.

>  	{
>  	}
>  

-- 
Regards,

Laurent Pinchart


More information about the libcamera-devel mailing list