You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Tim Apessos <ap...@verizon.net> on 2006/04/21 00:08:58 UTC
Update Manager thread safety question
I took all the useful advice given to me on my SVG Update problem and fixed
the problem that I was having. Thank you. I am curious about one other
item.
If I have two key listeners as in the example below and the user presses the
keys nearly simultaneously, are there any thread safety issues that I need
to worry about? As a precaution I've put flags in the listeners that I have
written so far to prevent a double click while an update has not occurred
but have not done so to prevent multiple keys from attempting to call the
Update Manager at the same time. Is this an issue that I need to be
concerned with?
Public class KeyListener1{
.
.
.
JSVGCanvas myCanvas;
myCanvas.getUpdateManger().getUpdateRunnableQueue().invokeLater(new
Runnable() {
public void run()
{
performSVGUpdate1();
}
});
}
Public class KeyListener2{
JSVGCanvas myCanvas;
myCanvas.getUpdateManger().getUpdateRunnableQueue().invokeLater(new
Runnable() {
public void run()
{
performSVGUpdate2();
}
});
}
Thanks,
Tim
RE: Update Manager thread safety question
Posted by th...@kodak.com.
Hi Tim,
"Tim Apessos" <ap...@verizon.net> wrote on 04/21/2006 01:45:14 AM:
> myCanvas.getUpdateManger().getUpdateRunnableQueue().invokeLater(new
> Runnable() public void run() { performSVGUpdate1(); } });
> 1. Are multiple occurrences of code execution like this thread safe?
Yes.
> 2. Is this simply placing all of the Runnable objects in a queue for the
> update manager to execute later?
Yes, the invoke* methods simply add a runnable to a queue and wake
the runnableQueue's thread if it is sleeping.
> 3. Would it cause a problem if the update manager thread were running
when
> we attempt to add another Runnable object to the queue?
No (barring bugs). The invokeLater/AndWait methods should be totally
thread safe, multiple threads should even be able to call the methods at
the same time and not have anything blow up. The running status of the
queue shouldn't come into in any way.
> Threads can be a source of great frustration to debug and I would like
to
> get a better understanding of what is going on so I can prevent any
> conflicts before they happen.
Yes, they are currently one of the hardest topics for programmers
(memory management used to be one - especially for non-GC languages,
but the tools have gotten very good). They are also likely to become
increasingly important now that virtually all processors are going
multi-core...
> When I write threads, I know exactly what is
> occurring and can prepare for it. Here there are tools that are
performing
> many methods for me and I am uncertain as to what precautions I should
take.
> Any additional insight into the matter that I haven't mentioned
regarding
> threads would be appreciated too.
The reason behind the RunnableQueue is to provide synchronized
access to the DOM - exactly the same purpose as the Swing Event thread.
The only thread that should ever read or write the DOM is the
UpdateManager
thread of the Document.
The most common problem I have seen with the RunnableQueue (other than
people not using it to read/write to the DOM) is that if you do an
invokeAndWait call from the Swing thread there is a chance for deadlock
(some DOM methods require querying the Canvas which can only be done in
the swing thread).
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
RE: Update Manager thread safety question
Posted by Tim Apessos <ap...@verizon.net>.
Thank you for the double click pointers. These methods are useful bits of
knowledge and it is heartening that I am not the only one to experience
these occurrences. However, the primary question that I have is thread
safety. My user can press multiple keys simultaneously or nearly
simultaneously. Each key press performs a different function and calls the
update manager with code similar to this:
myCanvas.getUpdateManger().getUpdateRunnableQueue().invokeLater(new
Runnable() {
public void run()
{
performSVGUpdate1();
}
});
}
1. Are multiple occurrences of code execution like this thread safe?
2. Is this simply placing all of the Runnable objects in a queue for the
update manager to execute later?
3. Would it cause a problem if the update manager thread were running when
we attempt to add another Runnable object to the queue?
Threads can be a source of great frustration to debug and I would like to
get a better understanding of what is going on so I can prevent any
conflicts before they happen. When I write threads, I know exactly what is
occurring and can prepare for it. Here there are tools that are performing
many methods for me and I am uncertain as to what precautions I should take.
Any additional insight into the matter that I haven't mentioned regarding
threads would be appreciated too.
Sincerely,
Tim Apessos
-----Original Message-----
From: Tonny Kohar [mailto:tonny@kiyut.com]
Sent: Thursday, April 20, 2006 10:55 PM
To: batik-users@xmlgraphics.apache.org
Subject: Re: Update Manager thread safety question
Hi,
On Java Standard MouseEvent, you could detect it is either single click
or double click by using mouseEvent.getClickCount(). The threshold
between click is determined by the JVM, which hopefully follows the
platform it run (Win XP, linux, etc)
Regards
Tonny Kohar
--
Sketsa
SVG Graphics Editor
http://www.kiyut.com
On Thu, 2006-04-20 at 23:49 +0100, Lewis Keen wrote:
> Tim,
>
> During my final year project development (Poker game) I too noticed
> the problem with double clicking on an element. I used this method on
> my "click" event listeners:
>
> public boolean isSingleClick(Event evt)
> {
> MouseEvent me=(MouseEvent)evt;
> return me.getDetail()==1;
> }
>
> where the MouseEvent is a org.w3c.dom.events.MouseEvent and not a
> standard java.awt.event.MouseEvent. This seemed to fix most of the
> problems I was having, however this is still the odd occasion where it
> does a double-click (not sure if its me or this dodgy mouse). I
> consequently removed the flags that I was originally using and it
> seemed to work fine.
>
> As to the two key listeners, it may be useful to have a brief
> explanation of what the listeners do and if the affect each other in a
> major way. I would imagine that the problem is similar to the problem
> a double-click would have, and I did have some problems with the lock
> not occuring quickly enough when doing a double-click. Sorry if this
> is waffle, its a little hard to explain :/
>
> Hope this helps,
>
> Lewis
>
> On 4/20/06, Tim Apessos <ap...@verizon.net> wrote:
> >
> >
> >
> > I took all the useful advice given to me on my SVG Update problem and
fixed
> > the problem that I was having. Thank you. I am curious about one other
> > item.
> >
> >
> >
> > If I have two key listeners as in the example below and the user presses
the
> > keys nearly simultaneously, are there any thread safety issues that I
need
> > to worry about? As a precaution I've put flags in the listeners that I
have
> > written so far to prevent a double click while an update has not
occurred
> > but have not done so to prevent multiple keys from attempting to call
the
> > Update Manager at the same time. Is this an issue that I need to be
> > concerned with?
> >
> >
> >
> > Public class KeyListener1{
> >
> > .
> >
> > .
> >
> > .
> >
> > JSVGCanvas myCanvas;
> >
> > myCanvas.getUpdateManger().getUpdateRunnableQueue().invokeLater(new
> > Runnable() {
> > public void run()
> > {
> > performSVGUpdate1();
> > }
> > });
> > }
> >
> >
> >
> >
> >
> >
> > Public class KeyListener2{
> >
> > JSVGCanvas myCanvas;
> >
> > myCanvas.getUpdateManger().getUpdateRunnableQueue().invokeLater(new
> > Runnable() {
> > public void run()
> > {
> > performSVGUpdate2();
> > }
> > });
> >
> >
> > }
> >
> >
> >
> > Thanks,
> >
> > Tim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Update Manager thread safety question
Posted by Tonny Kohar <to...@kiyut.com>.
Hi,
On Java Standard MouseEvent, you could detect it is either single click
or double click by using mouseEvent.getClickCount(). The threshold
between click is determined by the JVM, which hopefully follows the
platform it run (Win XP, linux, etc)
Regards
Tonny Kohar
--
Sketsa
SVG Graphics Editor
http://www.kiyut.com
On Thu, 2006-04-20 at 23:49 +0100, Lewis Keen wrote:
> Tim,
>
> During my final year project development (Poker game) I too noticed
> the problem with double clicking on an element. I used this method on
> my "click" event listeners:
>
> public boolean isSingleClick(Event evt)
> {
> MouseEvent me=(MouseEvent)evt;
> return me.getDetail()==1;
> }
>
> where the MouseEvent is a org.w3c.dom.events.MouseEvent and not a
> standard java.awt.event.MouseEvent. This seemed to fix most of the
> problems I was having, however this is still the odd occasion where it
> does a double-click (not sure if its me or this dodgy mouse). I
> consequently removed the flags that I was originally using and it
> seemed to work fine.
>
> As to the two key listeners, it may be useful to have a brief
> explanation of what the listeners do and if the affect each other in a
> major way. I would imagine that the problem is similar to the problem
> a double-click would have, and I did have some problems with the lock
> not occuring quickly enough when doing a double-click. Sorry if this
> is waffle, its a little hard to explain :/
>
> Hope this helps,
>
> Lewis
>
> On 4/20/06, Tim Apessos <ap...@verizon.net> wrote:
> >
> >
> >
> > I took all the useful advice given to me on my SVG Update problem and fixed
> > the problem that I was having. Thank you. I am curious about one other
> > item.
> >
> >
> >
> > If I have two key listeners as in the example below and the user presses the
> > keys nearly simultaneously, are there any thread safety issues that I need
> > to worry about? As a precaution I've put flags in the listeners that I have
> > written so far to prevent a double click while an update has not occurred
> > but have not done so to prevent multiple keys from attempting to call the
> > Update Manager at the same time. Is this an issue that I need to be
> > concerned with?
> >
> >
> >
> > Public class KeyListener1{
> >
> > .
> >
> > .
> >
> > .
> >
> > JSVGCanvas myCanvas;
> >
> > myCanvas.getUpdateManger().getUpdateRunnableQueue().invokeLater(new
> > Runnable() {
> > public void run()
> > {
> > performSVGUpdate1();
> > }
> > });
> > }
> >
> >
> >
> >
> >
> >
> > Public class KeyListener2{
> >
> > JSVGCanvas myCanvas;
> >
> > myCanvas.getUpdateManger().getUpdateRunnableQueue().invokeLater(new
> > Runnable() {
> > public void run()
> > {
> > performSVGUpdate2();
> > }
> > });
> >
> >
> > }
> >
> >
> >
> > Thanks,
> >
> > Tim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Update Manager thread safety question
Posted by Lewis Keen <ye...@gmail.com>.
Tim,
During my final year project development (Poker game) I too noticed
the problem with double clicking on an element. I used this method on
my "click" event listeners:
public boolean isSingleClick(Event evt)
{
MouseEvent me=(MouseEvent)evt;
return me.getDetail()==1;
}
where the MouseEvent is a org.w3c.dom.events.MouseEvent and not a
standard java.awt.event.MouseEvent. This seemed to fix most of the
problems I was having, however this is still the odd occasion where it
does a double-click (not sure if its me or this dodgy mouse). I
consequently removed the flags that I was originally using and it
seemed to work fine.
As to the two key listeners, it may be useful to have a brief
explanation of what the listeners do and if the affect each other in a
major way. I would imagine that the problem is similar to the problem
a double-click would have, and I did have some problems with the lock
not occuring quickly enough when doing a double-click. Sorry if this
is waffle, its a little hard to explain :/
Hope this helps,
Lewis
On 4/20/06, Tim Apessos <ap...@verizon.net> wrote:
>
>
>
> I took all the useful advice given to me on my SVG Update problem and fixed
> the problem that I was having. Thank you. I am curious about one other
> item.
>
>
>
> If I have two key listeners as in the example below and the user presses the
> keys nearly simultaneously, are there any thread safety issues that I need
> to worry about? As a precaution I've put flags in the listeners that I have
> written so far to prevent a double click while an update has not occurred
> but have not done so to prevent multiple keys from attempting to call the
> Update Manager at the same time. Is this an issue that I need to be
> concerned with?
>
>
>
> Public class KeyListener1{
>
> .
>
> .
>
> .
>
> JSVGCanvas myCanvas;
>
> myCanvas.getUpdateManger().getUpdateRunnableQueue().invokeLater(new
> Runnable() {
> public void run()
> {
> performSVGUpdate1();
> }
> });
> }
>
>
>
>
>
>
> Public class KeyListener2{
>
> JSVGCanvas myCanvas;
>
> myCanvas.getUpdateManger().getUpdateRunnableQueue().invokeLater(new
> Runnable() {
> public void run()
> {
> performSVGUpdate2();
> }
> });
>
>
> }
>
>
>
> Thanks,
>
> Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org