Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Standard Widget Toolkit (SWT) » Using GC from non-UI thread
Using GC from non-UI thread [message #452252] Wed, 16 March 2005 00:19 Go to next message
Ian Graham is currently offline Ian GrahamFriend
Messages: 24
Registered: July 2009
Junior Member
I understand that widgets should only be updated from the UI thread. =

However it's not clear to me whether a GC can be created, used, and =

disposed from a non-UI thread, to draw on an image. I was doing this wi=
th =

success under Windows, but under Linux my application would deadlock on =
a =

call to the GC.

The problem is essentially that I have a long-running rendering task tha=
t =

I want to run in the background, but if a GC cannot be used freely withi=
n =

a single non-UI thread, then it seems that my rendering code is going to=
=

have to be chock full of syncExecs. Also I have the problem that having=
=

the UI thread issue cancel() and then join() when appropriate is going t=
o =

have to take some real care because of the syncExecs within the job.

Could someone clarify what the constraints are on multithreading with GC=
s?

Thanks,
Ian Graham
Re: Using GC from non-UI thread [message #452272 is a reply to message #452252] Wed, 16 March 2005 16:31 Go to previous messageGo to next message
Silenio Quarti is currently offline Silenio QuartiFriend
Messages: 31
Registered: July 2009
Member
GC should be thread aware, but not thread safe. By that I mean, you can
use GC in threads other than the UI thread, but not on multiple threads at
the same time.

I strongly recommend that you create and destroy GCs (and other resources,
images, etc) in the UI thread, but other methods can be called from other
threads. Can you reproduce your deadlock consistently? What GC method was
deadlocking? If you have reproducible steps, could you open a bug report?

Thanks!
Silenio


Ian Graham wrote:

> I understand that widgets should only be updated from the UI thread.
> However it's not clear to me whether a GC can be created, used, and
> disposed from a non-UI thread, to draw on an image. I was doing this with
> success under Windows, but under Linux my application would deadlock on a
> call to the GC.

> The problem is essentially that I have a long-running rendering task that
> I want to run in the background, but if a GC cannot be used freely within
> a single non-UI thread, then it seems that my rendering code is going to
> have to be chock full of syncExecs. Also I have the problem that having
> the UI thread issue cancel() and then join() when appropriate is going to
> have to take some real care because of the syncExecs within the job.

> Could someone clarify what the constraints are on multithreading with GCs?

> Thanks,
> Ian Graham
Re: Using GC from non-UI thread [message #452283 is a reply to message #452272] Wed, 16 March 2005 21:33 Go to previous messageGo to next message
Ian Graham is currently offline Ian GrahamFriend
Messages: 24
Registered: July 2009
Junior Member
Thanks Silenio. Your first paragraph describes what I would have expect=
ed.

I _am_ curious then, why you recommend the creation and destruction of G=
Cs =

to take place in the UI thread? I did that for the image I'm drawing on=
, =

but didn't initially do that for the GC. However I do now create and =

destroy the GC in the UI thread using syncExec(quick solution - I will =

change it to do it outside the Job), but I still encounter the deadlock.=


As far as I can tell, the deadlock occurs for pretty much any GC method.=
=

The situation in which it occurs seems only to be when the UI thread is =
=

handling a ControlAdapter.controlResized() as a result of listening to a=
=

Canvas. It seems that something special about resizing my View seems to=
=

access the same lock as the GC that is used only within my single =

background Job.

And yes, I can produce the deadlock in less than a second simply by =

resizing my RCP app's main window. The actual deadlock occurs because I=
=

try to cancel() the Job and then join(). It really works fine if my =

cancellation is the result of an action triggered by a button push, but =
=

when it's from within the Canvas' ControlListener.controlResized() I get=
=

the deadlock.

I'll try to implement a modified version of the RCP tutorial that =

demonstrates the same problem, and then file it with a bug report. Unti=
l =

your answer, I wasn't sure if I was encountering a bug or if I was =

misusing GC.

Thanks!
Ian

On Wed, 16 Mar 2005 16:31:48 +0000 (UTC), Silenio Quarti =

<Silenio_Quarti@ca.ibm.com> wrote:

> GC should be thread aware, but not thread safe. By that I mean, you ca=
n =

> use GC in threads other than the UI thread, but not on multiple thread=
s =

> at the same time.
>
> I strongly recommend that you create and destroy GCs (and other =

> resources, images, etc) in the UI thread, but other methods can be =

> called from other threads. Can you reproduce your deadlock consistentl=
y? =

> What GC method was deadlocking? If you have reproducible steps, could =
=

> you open a bug report?
>
> Thanks!
> Silenio
>
>
> Ian Graham wrote:
>
>> I understand that widgets should only be updated from the UI thread. =
=

>> However it's not clear to me whether a GC can be created, used, and =
=

>> disposed from a non-UI thread, to draw on an image. I was doing this=
=

>> with success under Windows, but under Linux my application would =

>> deadlock on a call to the GC.
>
>> The problem is essentially that I have a long-running rendering task =
=

>> that I want to run in the background, but if a GC cannot be used =

>> freely within a single non-UI thread, then it seems that my renderin=
g =

>> code is going to have to be chock full of syncExecs. Also I have th=
e =

>> problem that having the UI thread issue cancel() and then join() whe=
n =

>> appropriate is going to have to take some real care because of the =

>> syncExecs within the job.
>
>> Could someone clarify what the constraints are on multithreading with=
=

>> GCs?
>
>> Thanks,
>> Ian Graham
Re: Using GC from non-UI thread [message #452284 is a reply to message #452272] Wed, 16 March 2005 22:03 Go to previous messageGo to next message
Ian Graham is currently offline Ian GrahamFriend
Messages: 24
Registered: July 2009
Junior Member
I've reported the problem as bug 88255, although I have yet to create a =
=

simple demo app that shows the problem. I'll get to it as soon as I can=
=

make my employer happy with a workaround!

Cheers,
Ian
Re: Using GC from non-UI thread [message #454201 is a reply to message #452272] Tue, 19 April 2005 00:03 Go to previous messageGo to next message
Ian Graham is currently offline Ian GrahamFriend
Messages: 24
Registered: July 2009
Junior Member
After refactoring to M6 and Java 5.0 as well as some other refactoring =

that included adding keyboard shortcuts, I've reencountered my deadlock =
=

problems. Now I'm getting deadlock on calls to ANY GC method, which see=
ms =

consistent with what Billy Biggs said in response to my invalid "bug" =

report https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D88255.

Have I possibly misunderstood what you said below, Silenio?

> GC should be thread aware, but not thread safe. By that I mean, you ca=
n =

> use GC in threads other than the UI thread, but not on multiple thread=
s =

> at the same time.

I understood this to mean that if I use a specific instance of GC from =

within only one thread(RCP Job), then there should be no problem, even i=
f =

I use a different instance in another thread. Now I realize you might =

have meant that only one GC should ever be used at any one time?

I only seem to have the problem when the UI thread is either responding =
to =

a view resize or a keyboard action - an action invoked by pressing a =

toolbar button doesn't seem to lock the GC. Also, no problem on Windows=
- =

only on Linux and Solaris.

> I strongly recommend that you create and destroy GCs (and other =

> resources, images, etc) in the UI thread, but other methods can be =

> called from other threads. Can you reproduce your deadlock consistentl=
y? =

> What GC method was deadlocking? If you have reproducible steps, could =
=

> you open a bug report?

I took your advice here, but it really seems that for actions invoked by=
=

keyboard shortcut I cannot simultaneously be calling ANY GC method from =
a =

non-UI thread. That doesn't seem right to me, though - I have trouble =

believing that X could be that bad. I'm really hoping that Eclipse or S=
WT =

is accidently applying a lock unnecessarily.

I'm thinking maybe my bug report IS valid, but should be reported on the=
=

Eclipse Platform rather than SWT. Could anyone confirm or deny that =

before I try to reopen it?

Thanks,
Ian
Re: Using GC from non-UI thread [message #454282 is a reply to message #454201] Tue, 19 April 2005 15:49 Go to previous messageGo to next message
Steve Northover is currently offline Steve NorthoverFriend
Messages: 1636
Registered: July 2009
Senior Member
You should be able to use multiple GC's as long as there is a GC per thread.
If you have a code snippet that shows the problem, enter a bug report.

"Ian Graham" <ian@kelman_.com> wrote in message
news:opspgc3hbfhrrzcq@cpd001pc...
After refactoring to M6 and Java 5.0 as well as some other refactoring
that included adding keyboard shortcuts, I've reencountered my deadlock
problems. Now I'm getting deadlock on calls to ANY GC method, which seems
consistent with what Billy Biggs said in response to my invalid "bug"
report https://bugs.eclipse.org/bugs/show_bug.cgi?id=88255.

Have I possibly misunderstood what you said below, Silenio?

> GC should be thread aware, but not thread safe. By that I mean, you can
> use GC in threads other than the UI thread, but not on multiple threads
> at the same time.

I understood this to mean that if I use a specific instance of GC from
within only one thread(RCP Job), then there should be no problem, even if
I use a different instance in another thread. Now I realize you might
have meant that only one GC should ever be used at any one time?

I only seem to have the problem when the UI thread is either responding to
a view resize or a keyboard action - an action invoked by pressing a
toolbar button doesn't seem to lock the GC. Also, no problem on Windows -
only on Linux and Solaris.

> I strongly recommend that you create and destroy GCs (and other
> resources, images, etc) in the UI thread, but other methods can be
> called from other threads. Can you reproduce your deadlock consistently?
> What GC method was deadlocking? If you have reproducible steps, could
> you open a bug report?

I took your advice here, but it really seems that for actions invoked by
keyboard shortcut I cannot simultaneously be calling ANY GC method from a
non-UI thread. That doesn't seem right to me, though - I have trouble
believing that X could be that bad. I'm really hoping that Eclipse or SWT
is accidently applying a lock unnecessarily.

I'm thinking maybe my bug report IS valid, but should be reported on the
Eclipse Platform rather than SWT. Could anyone confirm or deny that
before I try to reopen it?

Thanks,
Ian
Re: Using GC from non-UI thread [message #454294 is a reply to message #454282] Tue, 19 April 2005 19:12 Go to previous message
Ian Graham is currently offline Ian GrahamFriend
Messages: 24
Registered: July 2009
Junior Member
On Tue, 19 Apr 2005 11:49:27 -0400, Steve Northover =

<steve_northover@ca.ibm.com> wrote:

> You should be able to use multiple GC's as long as there is a GC per =

> thread.
> If you have a code snippet that shows the problem, enter a bug report.=


Thanks Steve. I'm working around the problem with lots of syncExecs at =
=

the moment, but I'm now convinced there IS a bug. Unfortunately it'll ne=
ed =

more than a snippet to demonstrate it, so it'll only be next month that =
=

I'll be able to take the time to put together a proper bug report with a=
=

small RCP example app. I filed =

https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D88255 right away, thinki=
ng I =

could provide more information later, but I guess that wasn't helpful.

Thanks again,
Ian
Previous Topic:Unable to vertically center a Label
Next Topic:CTRL+TAB
Goto Forum:
  


Current Time: Fri Mar 29 01:01:37 GMT 2024

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

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

Back to the top