http://imagej.273.s1.nabble.com/Contradiction-with-show-method-tp3693120p3693125.html
the proper sequence. If they aren't, it is a bug - one can never
by some commands not available in time for the next command. Since
> Micheal,
>
> My concern was/is unanticipated side effects like the one I got with
> show() then invert(). For example, if I ran two different filters in
> sequence (in the source code) that actually ran in sepaate
> threads, then
> would I need to worry about the results from the second filter
> affecting the
> first filter.
>
> David Webster
>
> On Wed, Apr 1, 2009 at 7:37 AM, Michael Schmid
> <
[hidden email]>wrote:
>
>> 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>
>>>>
>>>>