http://imagej.273.s1.nabble.com/Contradiction-with-show-method-tp3693120p3693124.html
show() then invert(). For example, if I ran two different filters in
> Hi David,
>
> sorry, I don't think that there is any list of commands that run in a
> separate thread. Essentially all I/O and display operations can have a
> separate thread, and your code should be multi-thread save concerning
> everything that involves a callback from Java (such as the paint method).
>
> Commands that you invoke from the ImageJ menus have separate threads. So in
> principle you could process two images or image stacks at the same time (in
> different threads). But don't do it with the same filter! Many filters use
> static variables that do not allow them to run with different parameters in
> parallel threads. Anyhow, working on two stacks at the same time usually
> won't be any faster than doing it sequentially - most ImageJ stack
> operations use parallel threads on multiprocessor machines anyhow
> (Edit>Options>Memory&Threads).
>
> There is "single-thread list":
>
> You can be sure that you have only one thread within one plugin where it
> does not give control to Java or involve a callback - unless you explicitly
> invoke more than one thread (obviously, PlugInFilters with
> PARALLELIZE_STACKS and the "preview" function of ExtendedPlugInFilters can
> use multiple threads).
>
> Also, there is only one event queue (event dispatch thread). So callbacks
> of a dialog like mouseMoved, keyTyped, buttonPressed etc. will all run in
> the same thread, usually named 'AWT-EventQueue-0'. Also, it is guaranteed
> that the callbacks will be in the correct sequence.
>
> Hope this helps a bit.
>
>
> Michael
> ________________________________________________________________
>
>
> On 31 Mar 2009, at 23:40, David Webster wrote:
>
> To All,
>>
>>
>> For what it’s worth, I wasn’t trying to “show” the results of the
>> invert()
>> before doing it. This was a completely unintended and unanticipated side
>> effect. But now I’m wondering what other methods may run in separate
>> threads. Is there a list?
>>
>>
>> David Webster
>>
>>
>> On Tue, Mar 31, 2009 at 11:37 AM, Gluender <
[hidden email]> wrote:
>>
>> Dear Herbert,
>>>
>>>>
>>>> as Michael explained correctly in his earlier response, that particular
>>>> effect can be explained by display running in a separate thread.
>>>>
>>>> However, I don't think this has anything to do with OO-programming at
>>>> all! It is certainly true that OO-programs do not execute linearly, as
>>>> typical procedural programs would. However, parallelism is not an
>>>> invention of object-orientation - in fact, some ancient FORTRAN and C
>>>> dialects made it much easier to express parallelism than does Java, for
>>>> example. Also, the noted "timeless parallel existence of objects"
>>>> applies to any declared variables, arrays or other data structures in
>>>> procedural programs as well.
>>>>
>>>> But perhaps I missed your real point? ...
>>>> --Wilhelm
>>>>
>>>>
>>> Wilhelm,
>>>
>>> my earlier comment agrees perfectly with Michael's statement. Furthermore
>>> I'm convinced that anybody who uses Java for e.g. image processing will
>>> sooner or later be confronted with this or a similar threading-issue. (I
>>> know what I'm speaking of.)
>>>
>>> With respect to your interesting objection I should like to remind you
>>> that
>>> I wrote:
>>> "Finally and quite important they [00-languages] allow for easier
>>> parallelisation of tasks..."
>>>
>>> I haven't stated that there aren't different or earlier or procedural
>>> approaches for parallelism and I'm aware of such dialects and additions.
>>> But
>>> they are dialects, mostly with limited scope, and mainly used in high
>>> performance computing.
>>>
>>> As far as "easier" is concerned, we shall see what the multiprocessor
>>> future will offer. Fact is that already today OO makes threading much
>>> easier
>>> (in fact in many cases you don't have to care -- and may suffer from it,
>>> such as the original poster David) than the mentioned procedural
>>> languages
>>> that require, as you state correctly, special dialects or additions.
>>>
>>> Concerning "timeless parallel existence of objects" you certainly missed
>>> my
>>> point if you think of objects such as "declared variables, arrays or
>>> other
>>> data structures". However, I'm pretty sure you know how my perhaps
>>> somewhat
>>> abstract view relates to the issue.
>>>
>>> Have a good evening
>>>
>>> Herbie
>>>
>>>
>>>
>>> -----Original Message-----
>>>>
>>>> From: ImageJ Interest Group [mailto:
[hidden email]] On
>>>>> Behalf Of Gluender
>>>>> Sent: Tuesday, March 31, 2009 10:36 AM
>>>>> To:
[hidden email]
>>>>> Subject: Re: Contradiction with show() method
>>>>>
>>>>> David,
>>>>>
>>>>> without going into the details of your problem, what you are
>>>>> experiencing is a peculiarity of the OO-trend in general and of Java
>>>>> (as an OO-language) in your specific situation.
>>>>>
>>>>> Objects in the first place have the property to exist and, well, only
>>>>> in the second place they may evolve or change...
>>>>>
>>>>> That said, procedures, such as those characteristic for signal
>>>>> processing tasks, must cope with the (in principle) parallel
>>>>> existence of objects in time.
>>>>>
>>>>> Now why are people using OO-languages to solve procedural problems?
>>>>> In the specific case because Java is, to a certain extent, platform
>>>>> independent.
>>>>> In general, because OO-languages are modern and under many
>>>>> circumstances easier to handle.
>>>>>
>>>>> Finally and quite important they allow for easier parallelisation of
>>>>>
>>>>
>>>> tasks, a property that in turn results from the more or less timeless
>>>>>
>>>>> parallel existence of objects.
>>>>>
>>>>
>>>>
>>>>> All that means for your problem that you have to take care for the
>>>>> correct sequence of what is handled in different threads which
>>>>> implies that you first need to know what is handle in different
>>>>> threads. Java provides tools for both but their application is
>>>>> sometimes a bit tricky.
>>>>>
>>>>> To All,
>>>>>>
>>>>>> Wilhelm, I reran my tests and got the same results. Howeve,
>>>>>>
>>>>> I should have
>>>>>
>>>>>> included my case 2 as a normal result. Only case 1 seems to
>>>>>>
>>>>> be odd. For what
>>>>>
>>>>>> it's worth, I am using IJ 1.42k.
>>>>>>
>>>>>> Micheal, I am running Windows XP2002 SP3. I am using a
>>>>>>
>>>>> Pentim 4 from 2005,
>>>>>
>>>>>> that is only a single core. I don't know if it mutithreds or not.
>>>>>> David
>>>>>>
>>>>>
>>>>> Please note that multiple threads do not imply their distribution to
>>>>> several processors.
>>>>>
>>>>>
>>>>>
>>>> Best
>>>>>
>>>>> Herbie
>>>>>
>>>>> On Mon, Mar 30, 2009 at 1:26 AM, Michael Schmid
>>>>>> <
[hidden email]>wrote:
>>>>>>
>>>>>> Hi David,
>>>>>>>
>>>>>>> Java is multi-threaded; displaying images is usually done
>>>>>>>
>>>>>> in a separate
>>>>>
>>>>>> thread. Especially on multiprocessor machines, this
>>>>>>>
>>>>>> improves performance.
>>>>>
>>>>>>
>>>>>>> Thus, it can easily happen that "im1.show();" displays
>>>>>>>
>>>>>> the image a few
>>>>>
>>>>>> thenths of a second after that method is called; at that
>>>>>>>
>>>>>> time the data are
>>>>>
>>>>>> modified already.
>>>>>>>
>>>>>>> (not a bug, a feature ;-)
>>>>>>>
>>>>>>> Michael
>>>>>>> ________________________________________________________________
>>>>>>>
>>>>>>>
>>>>>>> On 29 Mar 2009, at 22:34, David William Webster wrote:
>>>>>>>
>>>>>>> I am learning Java via th "monkey see, monkey do" method
>>>>>>>
>>>>>> and get what seems
>>>>>
>>>>>> to be a contradiction.
>>>>>>>>
>>>>>>>> I ran a test similar to the one shown in Burger and
>>>>>>>>
>>>>>>> Berge on page 502.(see
>>>>>
>>>>>> run method below). Without the updateAndDraw(), the invert()
>>>>>>>> result should not be display'ed. But,
>>>>>>>> In case 1, with the wait(2000) and updateAndDraw()
>>>>>>>>
>>>>>>> commented out,
>>>>>
>>>>>> I get the inverted image being displayed (It shouldn't be).
>>>>>>>> In case 2, I use the wait(200) and get only the original
>>>>>>>>
>>>>>>> image being
>>>>>
>>>>>> displayed.
>>>>>>>> In case 3, I add the updateAndDraw() and get the inverted image.
>>>>>>>> Only case 3 makes any sense
>>>>>>>>
>>>>>>>>
>>>>>>>> public void run(ImageProcessor ip) {
>>>>>>>>
>>>>>>>> ImageProcessor ip1 = ip.duplicate();
>>>>>>>> ImagePlus im1 = new ImagePlus("im1",ip1);
>>>>>>>> im1.show();
>>>>>>>> //IJ.wait(2000);
>>>>>>>> ip1.invert();
>>>>>>>> //im1.updateAndDraw();
>>>>>>>> }
>>>>>>>>
>>>>>>>> David Webster
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>> --
>>>
>>> Herbie
>>>
>>> ------------------------
>>> <
http://www.gluender.de>
>>>
>>>