Hi!
On 01/17/2017 04:43 PM, Joseph Qi wrote:
On 17/1/17 15:55, Eric Ren wrote:
Hi!
On 01/17/2017 03:39 PM, Joseph Qi wrote:
On 17/1/17 14:30, Eric Ren wrote:
We are in the situation that we have to avoid recursive cluster locking,
but there is no way to check if a cluster lock has been take
On 17/1/17 15:55, Eric Ren wrote:
Hi!
On 01/17/2017 03:39 PM, Joseph Qi wrote:
On 17/1/17 14:30, Eric Ren wrote:
We are in the situation that we have to avoid recursive cluster
locking,
but there is no way to check if a cluster lock has been taken by a
precess already.
Mostly, we can avoid
Hi!
On 01/17/2017 03:39 PM, Joseph Qi wrote:
On 17/1/17 14:30, Eric Ren wrote:
We are in the situation that we have to avoid recursive cluster locking,
but there is no way to check if a cluster lock has been taken by a
precess already.
Mostly, we can avoid recursive locking by writing code ca
On 17/1/17 14:30, Eric Ren wrote:
We are in the situation that we have to avoid recursive cluster locking,
but there is no way to check if a cluster lock has been taken by a
precess already.
Mostly, we can avoid recursive locking by writing code carefully.
However, we found that it's very hard
On 01/17/2017 02:30 PM, Eric Ren wrote:
> We are in the situation that we have to avoid recursive cluster locking,
> but there is no way to check if a cluster lock has been taken by a
> precess already.
>
> Mostly, we can avoid recursive locking by writing code carefully.
> However, we found that
We are in the situation that we have to avoid recursive cluster locking,
but there is no way to check if a cluster lock has been taken by a
precess already.
Mostly, we can avoid recursive locking by writing code carefully.
However, we found that it's very hard to handle the routines that
are invok
6 matches
Mail list logo
