Home » Modeling » EMF » EMF Transaction: Problems with InterruptedException
| EMF Transaction: Problems with InterruptedException [message #423894] |
Thu, 09 October 2008 04:46  |
Eclipse User |
|
|
|
Hi!
We are useing EMF Transaction in our current project to establish
synchronized model access.
The synchronization works fine, but sometimes we get
'InterruptedException' during a transaction should be started in the UI
thread.
The exceptions we get will allways be thrown in the very beginning of
the Lock#acquire(timeout, exclusive) method after checking if the
current thread was interrupted. In our case this method was called from
the Lock#uiSafeAcquire(exclusive) method after the AcquireJob returns
with the status 'UI_REENTERED_STATUS'.
I don't understand why the interrupted-check is necessary after the
UI_REENTERED_STATUS?
Is there any way to prevent those exceptions?
Best regards,
Bernd
|
|
|
| Re: EMF Transaction: Problems with InterruptedException [message #423917 is a reply to message #423894] |
Thu, 09 October 2008 13:13  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Bernd,
Yes, the Eclipse UI framework does frequently interrupt the UI thread,
and I'm not sure that it's a sound strategy (I had some discussion with
the Platform UI team about that a couple of years ago).
In any case, the acquire methods are following the Java best-practice of
always checking for interrupted status at the beginning of an API call
that may block. Perhaps the problem is that it isn't necessary to use
this external API in the re-entry scenario that you are seeing, but we
could use a private method that doesn't check for interrupt.
I'm not sure that I would be comfortable with this, though, because any
call that may block can also be interrupted during that wait, and if the
interrupt status isn't first cleared, then a subsequent interrupt may be
ineffectual.
As this uiSafeAcquire(...) API also includes cases where it is more
obviously appropriate to throw an InterruptedException, your client will
have to handle it, anyway. Perhaps it can just repeat the attempt in a
loop or something? Probably I need to know more about your particular
scenario ...
Cheers,
Christian
Bernd Vogt wrote:
> Hi!
>
> We are useing EMF Transaction in our current project to establish
> synchronized model access.
>
> The synchronization works fine, but sometimes we get
> 'InterruptedException' during a transaction should be started in the UI
> thread.
>
> The exceptions we get will allways be thrown in the very beginning of
> the Lock#acquire(timeout, exclusive) method after checking if the
> current thread was interrupted. In our case this method was called from
> the Lock#uiSafeAcquire(exclusive) method after the AcquireJob returns
> with the status 'UI_REENTERED_STATUS'.
>
> I don't understand why the interrupted-check is necessary after the
> UI_REENTERED_STATUS?
>
> Is there any way to prevent those exceptions?
>
> Best regards,
> Bernd
|
|
|
| Re: EMF Transaction: Problems with InterruptedException [message #423998 is a reply to message #423917] |
Tue, 14 October 2008 02:47 |
| Eclipse User |
|
|
|
Hi Christian,
I fear that there is no particular scenario in that the
InterruptedException occures. But I belive that in the most cases there
was a progress bar involved (e.g. a progress monitor dialog, or busy
cursor or sth.). So my assumption is that there is a ModalContext doing
sth. (e.g. code generation) and some viewer refreshes in the background.
I will strongly prefer the private non-throwing acquire call from the
uiSafeAcquire(...) method... because when I have to teach my colleagues
that they have to put their runExclusive calls into a loop repeating the
call if it failes... I get stone to death... :-)
Best regards,
Bernd
Christian W. Damus wrote:
> Hi, Bernd,
>
> Yes, the Eclipse UI framework does frequently interrupt the UI thread,
> and I'm not sure that it's a sound strategy (I had some discussion with
> the Platform UI team about that a couple of years ago).
>
> In any case, the acquire methods are following the Java best-practice of
> always checking for interrupted status at the beginning of an API call
> that may block. Perhaps the problem is that it isn't necessary to use
> this external API in the re-entry scenario that you are seeing, but we
> could use a private method that doesn't check for interrupt.
>
> I'm not sure that I would be comfortable with this, though, because any
> call that may block can also be interrupted during that wait, and if the
> interrupt status isn't first cleared, then a subsequent interrupt may be
> ineffectual.
>
> As this uiSafeAcquire(...) API also includes cases where it is more
> obviously appropriate to throw an InterruptedException, your client will
> have to handle it, anyway. Perhaps it can just repeat the attempt in a
> loop or something? Probably I need to know more about your particular
> scenario ...
>
> Cheers,
>
> Christian
>
> Bernd Vogt wrote:
>> Hi!
>>
>> We are useing EMF Transaction in our current project to establish
>> synchronized model access.
>>
>> The synchronization works fine, but sometimes we get
>> 'InterruptedException' during a transaction should be started in the
>> UI thread.
>>
>> The exceptions we get will allways be thrown in the very beginning of
>> the Lock#acquire(timeout, exclusive) method after checking if the
>> current thread was interrupted. In our case this method was called
>> from the Lock#uiSafeAcquire(exclusive) method after the AcquireJob
>> returns with the status 'UI_REENTERED_STATUS'.
>>
>> I don't understand why the interrupted-check is necessary after the
>> UI_REENTERED_STATUS?
>>
>> Is there any way to prevent those exceptions?
>>
>> Best regards,
>> Bernd
|
|
|
| Re: EMF Transaction: Problems with InterruptedException [message #424054 is a reply to message #423998] |
Wed, 15 October 2008 08:25 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Bernd,
Yes, the modal context is the beast that does the UI-thread-interrupting
thing that makes me unhappy.
Please raise an enhancement request, and we shall see about addressing
this in the 1.3 branch.
I must say that your colleagues seem to display an extreme reaction to
what, in my understanding, is a well-established technique in concurrent
applications where liveness is a concern. The repeated attempts to
acquire a resource are often timed waits, and usually the number of
retries is limited ...
Cheers,
Christian
Bernd Vogt wrote:
> Hi Christian,
>
> I fear that there is no particular scenario in that the
> InterruptedException occures. But I belive that in the most cases there
> was a progress bar involved (e.g. a progress monitor dialog, or busy
> cursor or sth.). So my assumption is that there is a ModalContext doing
> sth. (e.g. code generation) and some viewer refreshes in the background.
>
> I will strongly prefer the private non-throwing acquire call from the
> uiSafeAcquire(...) method... because when I have to teach my colleagues
> that they have to put their runExclusive calls into a loop repeating the
> call if it failes... I get stone to death... :-)
>
> Best regards,
> Bernd
>
> Christian W. Damus wrote:
>> Hi, Bernd,
>>
>> Yes, the Eclipse UI framework does frequently interrupt the UI thread,
>> and I'm not sure that it's a sound strategy (I had some discussion
>> with the Platform UI team about that a couple of years ago).
>>
>> In any case, the acquire methods are following the Java best-practice
>> of always checking for interrupted status at the beginning of an API
>> call that may block. Perhaps the problem is that it isn't necessary
>> to use this external API in the re-entry scenario that you are seeing,
>> but we could use a private method that doesn't check for interrupt.
>>
>> I'm not sure that I would be comfortable with this, though, because
>> any call that may block can also be interrupted during that wait, and
>> if the interrupt status isn't first cleared, then a subsequent
>> interrupt may be ineffectual.
>>
>> As this uiSafeAcquire(...) API also includes cases where it is more
>> obviously appropriate to throw an InterruptedException, your client
>> will have to handle it, anyway. Perhaps it can just repeat the
>> attempt in a loop or something? Probably I need to know more about
>> your particular scenario ...
>>
>> Cheers,
>>
>> Christian
>>
>> Bernd Vogt wrote:
>>> Hi!
>>>
>>> We are useing EMF Transaction in our current project to establish
>>> synchronized model access.
>>>
>>> The synchronization works fine, but sometimes we get
>>> 'InterruptedException' during a transaction should be started in the
>>> UI thread.
>>>
>>> The exceptions we get will allways be thrown in the very beginning of
>>> the Lock#acquire(timeout, exclusive) method after checking if the
>>> current thread was interrupted. In our case this method was called
>>> from the Lock#uiSafeAcquire(exclusive) method after the AcquireJob
>>> returns with the status 'UI_REENTERED_STATUS'.
>>>
>>> I don't understand why the interrupted-check is necessary after the
>>> UI_REENTERED_STATUS?
>>>
>>> Is there any way to prevent those exceptions?
>>>
>>> Best regards,
>>> Bernd
|
|
|
| Re: EMF Transaction: Problems with InterruptedException [message #424065 is a reply to message #424054] |
Wed, 15 October 2008 12:51 |
| Eclipse User |
|
|
|
Hi, Christian,
I now introduced a little utility to our project. The utility executes
exclusive runnables and handles upcoming InterruptedException with such
repeated attempts. I agree with you that this technique will help and is
also well-established in concurrent applications, but in cases in that I
only want to synchronize some model access - e.g. iterrating over a
EList - the loop (handling the InterruptedException) and the runnable
seems a bit oversized... But you are right, we want to acquire the lock
and this can fail for some reasons... so, we have to deal this.
But i'm not really sure if it must fail in the 'ui reentered case'. So
for this case I'll raise the enhancement request and let you decide
whats the best thing to do here.
Thanks for help,
Bernd
Christian W. Damus wrote:
> Hi, Bernd,
>
> Yes, the modal context is the beast that does the UI-thread-interrupting
> thing that makes me unhappy.
>
> Please raise an enhancement request, and we shall see about addressing
> this in the 1.3 branch.
>
> I must say that your colleagues seem to display an extreme reaction to
> what, in my understanding, is a well-established technique in concurrent
> applications where liveness is a concern. The repeated attempts to
> acquire a resource are often timed waits, and usually the number of
> retries is limited ...
>
> Cheers,
>
> Christian
>
> Bernd Vogt wrote:
>> Hi Christian,
>>
>> I fear that there is no particular scenario in that the
>> InterruptedException occures. But I belive that in the most cases
>> there was a progress bar involved (e.g. a progress monitor dialog, or
>> busy cursor or sth.). So my assumption is that there is a ModalContext
>> doing sth. (e.g. code generation) and some viewer refreshes in the
>> background.
>>
>> I will strongly prefer the private non-throwing acquire call from the
>> uiSafeAcquire(...) method... because when I have to teach my
>> colleagues that they have to put their runExclusive calls into a loop
>> repeating the call if it failes... I get stone to death... :-)
>>
>> Best regards,
>> Bernd
>>
>> Christian W. Damus wrote:
>>> Hi, Bernd,
>>>
>>> Yes, the Eclipse UI framework does frequently interrupt the UI
>>> thread, and I'm not sure that it's a sound strategy (I had some
>>> discussion with the Platform UI team about that a couple of years ago).
>>>
>>> In any case, the acquire methods are following the Java best-practice
>>> of always checking for interrupted status at the beginning of an API
>>> call that may block. Perhaps the problem is that it isn't necessary
>>> to use this external API in the re-entry scenario that you are
>>> seeing, but we could use a private method that doesn't check for
>>> interrupt.
>>>
>>> I'm not sure that I would be comfortable with this, though, because
>>> any call that may block can also be interrupted during that wait, and
>>> if the interrupt status isn't first cleared, then a subsequent
>>> interrupt may be ineffectual.
>>>
>>> As this uiSafeAcquire(...) API also includes cases where it is more
>>> obviously appropriate to throw an InterruptedException, your client
>>> will have to handle it, anyway. Perhaps it can just repeat the
>>> attempt in a loop or something? Probably I need to know more about
>>> your particular scenario ...
>>>
>>> Cheers,
>>>
>>> Christian
>>>
>>> Bernd Vogt wrote:
>>>> Hi!
>>>>
>>>> We are useing EMF Transaction in our current project to establish
>>>> synchronized model access.
>>>>
>>>> The synchronization works fine, but sometimes we get
>>>> 'InterruptedException' during a transaction should be started in the
>>>> UI thread.
>>>>
>>>> The exceptions we get will allways be thrown in the very beginning
>>>> of the Lock#acquire(timeout, exclusive) method after checking if the
>>>> current thread was interrupted. In our case this method was called
>>>> from the Lock#uiSafeAcquire(exclusive) method after the AcquireJob
>>>> returns with the status 'UI_REENTERED_STATUS'.
>>>>
>>>> I don't understand why the interrupted-check is necessary after the
>>>> UI_REENTERED_STATUS?
>>>>
>>>> Is there any way to prevent those exceptions?
>>>>
>>>> Best regards,
>>>> Bernd
|
|
|
Goto Forum:
Current Time: Wed Nov 05 06:31:42 EST 2025
Powered by FUDForum. Page generated in 0.05068 seconds |
Home