Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [EMF Transaction] Fair or Unfair?
[EMF Transaction] Fair or Unfair? [message #525887] Thu, 08 April 2010 07:59 Go to next message
Bernd Vogt is currently offline Bernd VogtFriend
Messages: 34
Registered: July 2009
Member
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 #525910 is a reply to message #525887] Thu, 08 April 2010 08:57 Go to previous messageGo to next message
Jonas Helming is currently offline Jonas HelmingFriend
Messages: 699
Registered: July 2009
Senior Member
Hi,
A short look at
TransactionalEditionDomain.runEclusive()
makes me think that all comes done to one synchronized block. And to my
best knowledge the strategy for synchronized blocks may be dependant on
the JVM?
Cheers
Jonas


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 #525928 is a reply to message #525910] Thu, 08 April 2010 10:14 Go to previous messageGo to next message
Bernd Vogt is currently offline Bernd VogtFriend
Messages: 34
Registered: July 2009
Member
Hi,

comments below.

Jonas wrote:
> A short look at
> TransactionalEditionDomain.runEclusive()
> makes me think that all comes done to one synchronized block.

Which synchronized block do you mean? The only one I see is the
TransactionImpl.start method (runExclusive -> startstartTransaction ->
new TransactionImpl.start). This only synchronizes the start method of
the newly create transaction, no other thread that calls runExclusive
has to wait here.

I think the main work will be done by the
org.eclipse.emf.transaction.util.Lock.uiSafeAcquire(boolean) method.
There are some other sync blocks but the method does mutch more... what
I don't understand...

Bernd
Re: [EMF Transaction] Fair or Unfair? [message #525989 is a reply to message #525887] Thu, 08 April 2010 13:22 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

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 #526025 is a reply to message #525989] Thu, 08 April 2010 14:33 Go to previous messageGo to next message
Bernd Vogt is currently offline Bernd VogtFriend
Messages: 34
Registered: July 2009
Member
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
Re: [EMF Transaction] Fair or Unfair? [message #526294 is a reply to message #526025] Fri, 09 April 2010 14:11 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

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
>
Re: [EMF Transaction] Fair or Unfair? [message #526523 is a reply to message #526294] Mon, 12 April 2010 07:35 Go to previous messageGo to next message
Bernd Vogt is currently offline Bernd VogtFriend
Messages: 34
Registered: July 2009
Member
Hi, Christian,

comments below.

Christian W. Damus wrote:
> 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.

I see. Even if the acquiration strategy will be unfair the same deadlock
is easily possible if the framework decides (randomly) 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.

Hm, ok. I think so too. I thought briefly about some other situations in
which it could happen but if there is no main-thread-keep-alive-thing I
think it would be more a handmade problem of lock orders then a problem
within the framework.

> I don't immediately have ideas what can be done about it.

Some time ago I had a very similar problem with a homemade lock object
that keeps the UI thread alive also. I decided to implement a realy
unfair (and a bit chaotic) lock strategy. The lock method did something
like that:

void lock(){
while( !acquired ) {
acquired = tryLock( TIMEOUT );
if ( !acquired ) Thread.sleep( IDLE );
}
}

Oh dear. The more I think about it, I come to the conviction that it
won't help us here...

> You should definitely raise a bug for the EMF Transaction team to consider.

Ok.

Cheers,

Bernd
Re: [EMF Transaction] Fair or Unfair? [message #526550 is a reply to message #526294] Mon, 12 April 2010 09:17 Go to previous message
Bernd Vogt is currently offline Bernd VogtFriend
Messages: 34
Registered: July 2009
Member
Raised bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=308806

Cheers,
Bernd
Previous Topic:[CDO] Disbale local copy / local caching
Next Topic:First steps in formulating EMF/Ecore-based patterns
Goto Forum:
  


Current Time: Fri Mar 29 13:43:30 GMT 2024

Powered by FUDForum. Page generated in 0.02650 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top