regarding multithreading

[Tanuki-no Torigava]

Qt Assistant quote:

void QMutex::lock ()

Locks the mutex. If another thread has locked the mutex then this call will block until that thread has unlocked it.

Calling this function multiple times on the same mutex from the same thread is allowed if this mutex is a recursive mutex. If this mutex is a non-recursive mutex, this function will dead-lock when the mutex is locked recursively.

See also unlock().

bool QMutex::tryLock ()

Attempts to lock the mutex. If the lock was obtained, this function returns true. If another thread has locked the mutex, this function returns false immediately.

If the lock was obtained, the mutex must be unlocked with unlock() before another thread can successfully lock it.

Calling this function multiple times on the same mutex from the same thread is allowed if this mutex is a recursive mutex. If this mutex is a non-recursive mutex, this function will always return false when attempting to lock the mutex recursively.

According to Assistant tryLock on non-recursive mutexes is better way than lock which can lead the thread to deadlock while tryLock not. It will pop up immediately. Also to escape race condition described in your post I suggest to use wait time based on random condition. In fact lock will lead threads in a queue block and stand still while you want them to do something useful.

[wysota]

According to Assistant tryLock on non-recursive mutexes is better way than lock which can lead the thread to deadlock while tryLock not.

Somehow I can't see the word "better" in what you quoted. And yes, tryLock() will not dead-lock, it will simply always fail. Deadlock is a logical error. If your application deadlocks, it is not caused by the fact you used lock() instead of tryLock() but rather that your logic is invalid (i.e. you used a non-recursive mutex in a resursive situation).

Also to escape race condition described in your post I suggest to use wait time based on random condition.

Seems like a "russian roulette" approach... "If we're lucky, it won't starve".

In fact lock will lead threads in a queue block and stand still while you want them to do something useful.

That's the whole point of using thread synchronization. Threads won't be doing anything useful if you starve them. If you want to do something while waiting for the critical section then do it in another thread that won't have to wait - use a thread pool or something.

[Tanuki-no Torigava]

Seems like a "russian roulette" approach... "If we're lucky, it won't starve".

I prefer Monte-Carlo

That's the whole point of using thread synchronization. Threads won't be doing anything useful if you starve them. If you want to do something while waiting for the critical section then do it in another thread that won't have to wait - use a thread pool or something.

I thought that we are talking about processing in 2 different threads. That is the whole point. If you need to reenter the same thread then yes. You are right in all posts. But for two and more threads I do prefer to stick with tryLock approach.

P.S. It is quite interesting for me to understand more about different ways to write correct non-blocking thread-based code for myself. So, may be you will be so kind to join a discussion in different topic about that particularly. And thank you for your patience answering my potentially stupid questions

[wysota]

I prefer Monte-Carlo

Monte-Carlo only makes sense for a vast sample space, like 10000 samples at least. I doubt you're running 10000 threads at once in your application.

But for two and more threads I do prefer to stick with tryLock approach.

Do that but please don't post under my posts stating that it is better to use tryLock() instead of lock() because I will always be contesting that statement. It is plainly false and you have no arguments for backing up your claims. You failed to prove any of your points. And no matter the number of threads - tryLock() simply shouldn't be used. Ever (unless you have a very very very specific reason to do that). There is not one thing you could do with tryLock() that you couldn't do without it but there are many things that can be done without tryLock() but not with tryLock(). The only place where I see tryLock() could be useful is when dealing with a time-critical resource in a real-time operating system where you prefer to fail an operation than to extend past a designated time frame. But certainly not in a general case.

[Tanuki-no Torigava]

Ok. Just looked into tryLock implementation in original Qt code. tryLock() is a non-blocking alternative to lock(). Also it is simpler. If you do prefer complete blocking solution then lock() is the only choice. But non-blocking implementation requires tryLock(). Agree?

[wysota]

But non-blocking implementation requires tryLock(). Agree?

No. Read about lock-free data structures.

[mohanakrishnan]

hi wysota/all
thanks for ur valuable info.i ll try and come back...