Re: [ jEdit-devel ] dealing with deadlocks in jedit - avoid them

[Matthieu C. <cho...@gm...>]

2012/5/29 Jarek Czekalski <jar...@po...>

>
>
> W dniu 2012-05-29 10:13, Matthieu Casanova pisze:
>
> Hi,
>
>
> 2012/5/29 Jarek Czekalski <jar...@po...>
>
>> There are as many buffer locks in jedit as open buffers. So they also
>> should be ordered. Implementing Comparable interface would be enough to
>> make it work. Then it will be said that multiple buffer locks must be
>> acquired in the increasing order.
>>
>
>  I don't understand that. How would you order them ? When you require a
> lock, if it is not taken by something else you get it, otherwise you wait.
> Are you thinking about creating a waiting queue and that comparator would
> sort the threads waiting to find the good one ?
> I find that it is complex and I'm not sure of the benefit. We now use a
> ReentrantReadWriteLock from the java api, I would not like to replace it if
> that's the idea.
>
>
> No, no complex computator. Think about threads T1 and T2, which both want
> readLock on files A and B. Now:
> 1. T1 acquires A, T2 acquries B - no problem so far
> 2. T1 wants B, T2 wants A - it's a deadlock
> I haven't seen such a deadlock in jedit, but it's theoretically possible.
> When I design anti-deadlock documentation I think of this case also. If the
> buffers are ordered, no matter how, both T1 and T2 should first try to
> acquire A, then B. No deadlock possible in such case. A thread must find a
> way itself to obey this sequence. Otherwise it will be blamed for the
> deadlock.
>

It is only possible if requiring write locks, not read locks.
For example
1. T1 aquires A write lock, T2 aquires B write lock
2. T1 wants B read (or write) lock T2 wants A read (or write) lock.

I think that a write lock must only be aquired in EDT thread (that would be
logical since Swing requires that any change that could modify the display
must be done in the EDT thread).
In that case it would solve the problem don't you think ?



>
>> What do you think guys? Is it realistic? Maybe the suggested order is
>> not acceptable for some jobs to be done? One of the concerns is reading
>> a VFSFile which requires obtaining EDT to get the session in a proper
>> way. It would be nice to have a possibility of tryLock() on EDT. I have
>> a sophisticated extension to the plan in mind, but will not reveal it
>> until it turns out to be desired.
>
>
>  But if you try the lock and you cannot get it now, what would you do ?
>
> Back out. Report failure. For example a parser that couldn't acquire the
> lock reports that "Parsing failed, due to temporary unavailable resources".
>
>
>  In fact are you talking about deadlocks only or about jEdit freezing
> because of heavy tasks done on EDT thread too ?
> Because I didn't see a deadlock in my jEdit since a very long time.
>
> But you may see 2 deadlock bug reports in jedit plugin bugs tracker.
>

I see, I think that's because we didn't write rules that are clear enough
about locking.

Matthieu