Antwort: Re: Arrays and thread safety

Posted by Joachim Wesner on May 07, 2009; 3:16pm
URL: http://imagej.273.s1.nabble.com/Arrays-and-thread-safety-tp3692620p3692628.html

Interesting "Thread" :-)

However, IMHO there should be no difference sd Michael suggests if you have
truely different arrays or only disjoint parts in the same array!?

In the end, it´s all about "memory adresses". (Cash trashing could be a
point which might be in favour of each of both version, depending of the
size of the image and the cashes)

Yet, depending on the "hotspot optimization" of the Java virtual machine,
could there be a difference witrh regard to (not fully optimized away)
bounds checking
or does the VM even check for possible access conflicts? In the latter
case, when it knows it´s clearly different "object" it could avoid that
check.
However, I would assum that is the responsibilty of the programmer and
finally the meory hardware to soemhow serialze the access. If you write
non-thread-safe code, the VM can´t fix it in the general case.

Mit freundlichen Grüßen / Best regards

Joachim Wesner
____________________________________________

Leica Microsystems CMS GmbH | GmbH mit Sitz in Wetzlar | Amtsgericht
Wetzlar  HRB 2432
Geschäftsführer:  Dr. Stefan Traeger | Dr. Wolf-Otto Reuter | Dr. David Roy
Martyr | Colin Davis


                                                                           
             Thomas Boudier                                                
             <thomas.boudier@S                                            
             NV.JUSSIEU.FR>                                             An
             Gesendet von:              [hidden email]                
             ImageJ Interest                                         Kopie
             Group                                                        
             <[hidden email].                                       Thema
             GOV>                       Re: Arrays and thread safety      
                                                                           
                                                                           
             07.05.2009 17:07                                              
                                                                           
                                                                           
              Bitte antworten                                              
                    an                                                    
              ImageJ Interest                                              
                   Group                                                  
             <[hidden email].                                            
                   GOV>                                                    
                                                                           
                                                                           




Hi Michael,

I mean when each thread work on separate arrays, I split my images in 4
parts (when I have 4 cpus) with overlap and process each part with a
thread and then recombine them.

Thomas


Michael Doube a écrit :

> Hi Thomas
>
>> I've noticed that it works much faster when each thread works on its
>> own separate piece of image.
>
> Do you mean when each thread is given a 1D array from a 2D array (e.g.
> workArray[z][]), or when each thread is given a separate range in a 1D
> workArray[]?
>
> Mike
>
>
>> Thomas
>>
>>
>> Michael Doube a écrit :
>>> Hi all
>>>
>>> I recently wrote a multithreaded plugin
>>> (http://doube.org/plugins.html#purify) to find the biggest particle
>>> in a stack and delete all others.  It works by running a particle
>>> joining method on separate chunks (sets of slices), where each chunk
>>> is processed in a separate thread. The chunks are then stitched back
>>> together; the particle relabelling method replaceLabels() is run
>>> multithreaded.  However, it seems that sometimes stitching fails - I
>>> can run with the same conditions on the same stack and get different
>>> results, so I guess that the threads are clobbering each other.
>>>
>>> I have 2 questions:
>>>
>>> 1) is there any difference in thread safety to use 1D work arrays
>>> with (x,y,z) indexing like
>>>
>>>  workArray[index] where index = z * width * height + y * width + x
>>>
>>> and each thread given a discrete range of z values to work on
>>>
>>> or to use 2D arrays with (x,y,z) indexing like
>>>
>>>  workArray[z][index] where index = y * width + x
>>>
>>> and each thread given a z to work on
>>>
>>> (The plugin uses 1D arrays at the moment)
>>>
>>>
>>> 2) the multithreaded version of replaceLabels() runs within a nested
>>> for loop that iterates over voxels.  A single thread checks label
>>> values and each time a particle label needs to be replaced, nThreads
>>> instances of replaceLabels() run, replacing labels in discrete slices
>>> indexed in a 1D work array.  Is it possible that one thread, having
>>> finished its job of replaceLabels(), iterates through the for loop
>>> while the other thread(s) is(are) still running replaceLabels()?
>>>
>>> Any comments appreciated,
>>>
>>> Mike
>>>
>>>
>
>

--
   /**********************************************************/
      Thomas Boudier, MCU Université Pierre et Marie Curie,
      IFR 83. Bat B 7ème étage, porte 709, Jussieu.
      Tel : [phone]  Fax : [phone]
/*******************************************************/



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________