0

http://doc.qt.io/archives/qt-4.7/qmutexlocker.html

This class locks the mutex in its constructor, so if an error occurs while mutex creation, will we be able to know what error was it (constructor doesn't return anything)?

Is this a disadvantage somehow?

Am I missing a point here?

Christophe Weis
  • 2,518
  • 4
  • 28
  • 32
Aquarius_Girl
  • 21,790
  • 65
  • 230
  • 411
  • If you are worried about a `bad_alloc`, then create the mutex first, testing that before creating the locker. What specifically were you worried about happening? – cmannett85 Aug 13 '12 at 12:02
  • @cbamber85 I thought that QMutexLocker class can be used "safely" - without worrying about "anything"! Will it be a bad design if instead of locking the mutex in the constructor, we lock it in a separate class function which returns the error code? – Aquarius_Girl Aug 13 '12 at 12:05

2 Answers2

1

You may be confusing mutexes and locks. The mutex is the shared synchronisation object. Locks are lo­cal objects, local to each execution context, which effect synchronisation by means of locking the com­mon mutex. Thus the mutex already has to exist in order for a lock to make sense:

Foo sharedData;           // \ global/
QMutex sharedDataMX;      // / shared

void run_me_many_times()
{
    QMutexLocker lk(&sharedDataMX);

    // access "sharedData"
}
Kerrek SB
  • 464,522
  • 92
  • 875
  • 1,084
  • thanks, but `pthread_mutex_lock` returns several kinds of errors like EBUSY etc. So, mutex variable might be existing for sure, but error can still occur like - EAGAIN – Aquarius_Girl Aug 13 '12 at 12:09
  • 2
    A simple SBRM locker class like your `QMutexLocker` is not suitable for complex locking semantics. All it does provides a simple blocking-lock/unlock. If you need something more refined, you need to interface the mutex directly (e.g. some form of `try_lock`). A C++-style simple `lock()` cannot fail other than via an exception, so if your code flows past the `lock()` call, you're guaranteed to have the lock. – Kerrek SB Aug 13 '12 at 12:11
1

QMutexLocker takes a pointer to (and deals with) a QMutex object - not a pthread_mutex_t object (even if a QMutex might be implemented on top of a pthread_mutex_t).

Locking/unlocking a QMutex object doesn't return any kind of error code (QMutex::lock() and QMutex::unlock() return void).

Any errors that might occur at the lower "pthread-level" will either be handled internally by the QMutex object, result in a C++ exception, or result in a defect (such as deadlock) in your code (for example if you try to recursively acquire a QMutex that's non-recursive).

Michael Burr
  • 333,147
  • 50
  • 533
  • 760
  • so it is not a safe thing to use, this means! I was swayed away by its being a part of Qt. – Aquarius_Girl Aug 14 '12 at 03:28
  • 2
    Qt makes design choices not to provide certain types of error handling for the sake of a nice API - most notably it does not use exceptions. However, having just looked at the relevant Qt source (I would suggest you do the same if you have concerns): EBUSY is not relevant because that only applies to tryLock(). EAGAIN also does not apply because Qt uses it's own counter for recursive locks. Other errors could of course happen, but they're extremely unlikely. If you need that level of error-checking you will need to find another solution, but it's 'safe' for the vast majority of uses. – Dan Milburn Aug 14 '12 at 09:14