Login  Register

Re: Contradiction with show() method

Posted by David Webster on Mar 31, 2009; 9:40pm
URL: http://imagej.273.s1.nabble.com/Contradiction-with-show-method-tp3693120p3693122.html

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>
>