On 16 October 2010 08:55, Marcel Taeumel
<marcel.taeumel at student.hpi.uni-potsdam.de> wrote:
> So Set>>do: is not thread-safe. That's an interesting point. I think it would really improve the quality of the present API if all standard containers would be thread-safe. Is there already a project that tries to achieve this?
>

We are discussed this before.
My own opinion on it: do not try to make standard collections like Set
thread safe,
because it will lead to fine-grained locking, which will make image
crawl like a snail.
This is wrong direction.

You should use either specialized containers, like SharedQueue,
or protect your data from concurrent access at more coarse-grained level.


> Ciao,
> Marcel
>
> -----Ursprüngliche Nachricht-----
> Von: squeak-dev-bounces at lists.squeakfoundation.org [mailto:squeak-dev-bounces at lists.squeakfoundation.org] Im Auftrag von Andreas Raab
> Gesendet: Samstag, 16. Oktober 2010 07:38
> An: The general-purpose Squeak developers list
> Betreff: [squeak-dev] Re: Example of non-concurrent code :)
>
> On 10/15/2010 10:16 PM, Igor Stasenko wrote:
>> On 16 October 2010 08:00, Andreas Raab<andreas.raab at gmx.de>  wrote:
>>> On 10/15/2010 9:41 PM, Igor Stasenko wrote:
>>>>
>>>> Here, the bug:
>>>> first it sends #peekEvent and its not nil.
>>>> Okay, then after some logic voodo, it sends nextEvent, without
>>>> precaution, that it may also answer nil!
>>>>
>>>> So, if some other process get between these two sends (*a*, *b*) and
>>>> fetch/flush all events, a code will fail,
>>>
>>> But there is no such code. The method in question is run from within Morphic
>>> so unless there is a concurrent thread which for some reason flushes the
>>> event queue[*1], this case simply cannot happen. The shared queue used for
>>> synchronization here is specifically for synchronizing the event queue with
>>> the Morphic event loop. It's not for general purpose
>>> let's-just-dump-all-events-at-random-points-in-time usage.
>>>
>>> [*1] I would claim that such code itself buggy. Flushing the event queue
>>> should be synchronized with Morphic.
>>
>> There are 209 references to Sensor in my image.
>> How i can be sure that every place does not using it outside a Morphic
>> UI process?
>
> You can be just as sure as arguing that Set>>do: isn't thread safe. How
> can you be sure that every place does not use it in a separate thread?
> This kind of argument is pointless. If you have evidence that this is
> indeed a problem, then let's fix it (rather: let's fix the place that
> accesses UI stuff from another thread). But let's not pick a random
> method in the image and go all wild about that it might perhaps not be
> thread safe.
>
> Cheers,
>   - Andreas
>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.