w*s
发帖数: 7227 | 1 avoid having locks (if possible),
avoid having more than one lock
always take the locks in the same order.
are these enough ?
thanks ! |
g*****g
发帖数: 34805 | 2 Depends on the support, some language like java allows you to
try lock, you can try lock all the locks needed. And release
locks if any of them is not successful.
【在 w*s 的大作中提到】
: avoid having locks (if possible),
: avoid having more than one lock
: always take the locks in the same order.
: are these enough ?
: thanks !
|
w*s
发帖数: 7227 | 3 How about c++ ?
i searched online, seems there're algorithms to detect deadlocks,
but not sure companies will implements these.
The only thing i remember is to acquire locks in orders for each thread. But
was not accepted in the interview.
【在 g*****g 的大作中提到】
: Depends on the support, some language like java allows you to
: try lock, you can try lock all the locks needed. And release
: locks if any of them is not successful.
|
M**u
发帖数: 10158 | 4 pthread_mutex_trylock
But
【在 w*s 的大作中提到】
: How about c++ ?
: i searched online, seems there're algorithms to detect deadlocks,
: but not sure companies will implements these.
: The only thing i remember is to acquire locks in orders for each thread. But
: was not accepted in the interview.
|
M**u
发帖数: 10158 | 5 in pthread, there is error-check mutex
Default mutex is fast mutex, which cannot check
But
【在 w*s 的大作中提到】
: How about c++ ?
: i searched online, seems there're algorithms to detect deadlocks,
: but not sure companies will implements these.
: The only thing i remember is to acquire locks in orders for each thread. But
: was not accepted in the interview.
|
l*****o
发帖数: 473 | 6 Using the same order should be enough. |
B********e
发帖数: 1062 | 7 There is a silly but workable method:
never ever use lock/unlock by itself. use scoped_lock.
【在 w*s 的大作中提到】
: avoid having locks (if possible),
: avoid having more than one lock
: always take the locks in the same order.
: are these enough ?
: thanks !
|
w*s
发帖数: 7227 | |
l*****o
发帖数: 473 | 9 pthread_mutex_trylock won't help at all.
Considering the case like this:
Thread 1:
lock(A);
lock(B);
unlock(B);
unlock(A);
Thread 2:
lock(B);
lock(A);
unlock(A);
unlock(B);
Let's assume that Thread 1 get lockA at first.
Now when thread 2 get lockB, it is definitely allowed (even use pthread_try_
lock) to acquire lockB because no one is acquiring that.
Then if T1 are holding lockA and T2 are holding lockB, then there is no use
to use pthread_mutex_trylock at all because T1 won't release lockA and T2
won't release lockB.
When thread
【在 M**u 的大作中提到】
: pthread_mutex_trylock
:
: But
|
