No subject


Tue Nov 2 11:10:42 EDT 2010


there are some pitfalls than I did not take in account?

Thanks,
Volodymyr

On Thu, Nov 18, 2010 at 1:45 PM, Dan Mueller <dan.muel at gmail.com> wrote:
> Hi Volodymyr,
>
> (I have also posted to Insight-Users mailing list)
>
> This is a good question. I would say that SingleBitBinaryImage is NOT
> safe for writing from multiple threads. The reason being that another
> thread may have written the 32-bit mask before the current thread
> does. The only way it can be thread safe is if the multi-threader
> divides the image into regions exactly aligned with the underlying
> 32-bit masks (eg. the regions are modulo 32).
>
> Please add a review to the Insight Journal, and I will try to think of
> the best way to address this...
>
> Regards, Dan
>
> On 18 November 2010 11:44, =D0=92=D0=BB=D0=B0=D0=B4=D0=B8=D0=BC=D0=B8=D1=
=80 =D0=A2=D0=BA=D0=B0=D1=87=D1=83=D0=BA <vova.tkachuk at gmail.com> wrote:
>> Hello!
>>
>> I read your article "Alternative Memory Models for ITK Images" at ITK
>> journal. And I want to use itk::SingleBitBinaryImage.
>>
>> But I cannot clearly understand, how it feel with multi threading. It
>> is definitely safe for read, what about writing? If two regions do not
>> overlap in pixels, but in fact use the same "unsigned int" memory
>> block? For instance one use first 16 bits (pixels), and another - last
>> 16 bits. Is it safe for parallel writing? Can I use
>> SingleBitBinaryImage<> as output for standard ITK filters (such as
>> BinaryThresholdFilter) as it, or additional work around needed?
>>
>>
>> Thank you for answers,
>>
>> Volodymyr Tkachuk
>>
>


More information about the Insight-users mailing list