|
|
|
Re: [EMF Transaction] Fair or Unfair? [message #525989 is a reply to message #525887] |
Thu, 08 April 2010 13:22 |
|
Hi, Bernd,
The transactional editing domain uses a FIFO queue to track threads that
are waiting for the lock. So, it can be characterized as "fair." I had
originally considered providing an unfair option and even a
prioritization option, but didn't have a use case for it and didn't want
to open up other priority-based problems. :-)
Cheers,
Christian
On 08/04/10 03:59 AM, Bernd Vogt wrote:
> Hi,
>
> behaves the transaction framework in a fair or in a unfair way? In other
> words: Will a transaction be granted to the longest-waiting thread, or
> doesn't the transaction framework care about lock ordering?
>
> Kind regards,
>
> Bernd
|
|
|
|
Re: [EMF Transaction] Fair or Unfair? [message #526294 is a reply to message #526025] |
Fri, 09 April 2010 14:11 |
|
Hi, Bernd,
I see. This is, indeed, a sticky situation. So, some thread had the
transaction lock when main and Worker-3 tried for it, then released it,
but they are already deadlocked on one another in the workspace, so now
neither is available to receive the lock. Ouch.
This isn't really a problem with fairness: an unfair approach could
just as easily stick trying to give the lock to the main thread. This
is more a consequence of the strategy of keeping the UI thread alive by
running the event loop while it waits for a lock. I don't immediately
have ideas what can be done about it.
You should definitely raise a bug for the EMF Transaction team to consider.
Cheers,
Christian
On 08/04/10 10:33 AM, Bernd Vogt wrote:
> Hi, Christian,
>
> thx for answer. The reason for my question are some thread dumps
> reflecting deadlocks occured in our product. For me its not clear what
> has caused this deadlocks.
>
> The thread dumps looks like this:
>
> Thread [main] (Suspended)
> (WorkManager locked)
> WorkManager.checkIn()
> JavaModelManager.initializeAllContainers()
> Display.readAndDispatch()
> (need transaction -> not acquired)
> Viewer.refresh()
> Main.main(String[])
>
> Thread [Worker-3] (Suspended)
> (need transaction)
> ourResourceListener.resourceChanged()
> NotificationManager.notify()
> (WorkManager locked)
> Workspace.endOperation()
> Worker.run()
>
> Note: There is no other thread with an active transaction.
>
> So my suspicion is that the [main] thread has acquired the transaction
> before [Worker-3]. And the transaction framework wants to be "fair" and
> wants to give the free transaction to [main].
>
> Regards,
> Bernd
>
> Christian W. Damus wrote:
>> Hi, Bernd,
>>
>> The transactional editing domain uses a FIFO queue to track threads
>> that are waiting for the lock. So, it can be characterized as "fair."
>> I had originally considered providing an unfair option and even a
>> prioritization option, but didn't have a use case for it and didn't
>> want to open up other priority-based problems. :-)
>>
>> Cheers,
>>
>> Christian
>
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04300 seconds