http://imagej.273.s1.nabble.com/Contradiction-with-show-method-tp3693120p3693123.html
separate thread. Essentially all I/O and display operations can have
Commands that you invoke from the ImageJ menus have separate threads.
same time (in different threads). But don't do it with the same
run with different parameters in parallel threads. Anyhow, working on
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'.
> 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>
>>