On Fri, Aug 4, 2017 at 7:06 PM, Alidra Abdelghani via Pharo-users <
pharo-users@lists.pharo.org> wrote:

>
>
> ---------- Forwarded message ----------
> From: Alidra Abdelghani <alidran...@yahoo.fr>
> To: Guillermo Polito <guillermopol...@gmail.com>
> Cc: Any question about pharo is welcome <pharo-users@lists.pharo.org>,
> "Stéphane Ducasse" <stephane.duca...@inria.fr>, farid arfi <
> arf...@hotmail.com>
> Bcc:
> Date: Fri, 4 Aug 2017 19:06:00 +0200
> Subject: Re: [Pharo-users] Threads safety in Pharo
> Thanks Guille for your answer,
> From what I understand, it is mainly a synchronisation problem. Why cant'
> existing synchronisation mechanisms (semaphores and mutex) be used?
>

They can but it means to analyse existing code and produce thread safe one.





> Abdelghani
>
>
> On 31 Jul 2017, at 18:44, Guillermo Polito <guillermopol...@gmail.com>
> wrote:
>
> I believe there is no such a document. It would be however interesting to
> investigate it a bit deeper. In general, the problem we talk about when we
> talk about thread safety is the following: Can we run a workspace in a
> separate thread than a browser and provide correct results? Can we run two
> browsers concurrently and change code from both of them?
>
> The thread safety problem has several levels I'd say:
>
>  - the kernel of the language (classes, methods, compilation, and so on)
> cannot safely be modified while other threads are running. Thus, if we
> compile a new version of a method in a thread, that could break a separate
> thread that was using that method.
>
>  - there are several libraries using global state. We should investigate
> if they work correctly when using them concurrently.
>     E.g., source code management is not thread safe. This could cause a
> source code corruption if several methods are modified concurrently.
>     Like that, we sh n ould investigate all libraries and see what should
> be adapted and if there is a need at all.
>
>
>  - in a third level, general core libraries (collections, networking,
> files, etc) are not designed to be thread safe and that is natural. For
> example, most of the time you don't want that your collection is accessed
> concurrently. For such cases, some libraries could provide some
> extensions/wrappers/whatsoever to provide some synchronization mechanism.
> Otherwise it is the responsibility of the user to synchronize usages with
> semaphores/mutexes.
>
>
> On Mon, Jul 31, 2017 at 1:38 AM, Alidra Abdelghani via Pharo-users <
> pharo-users@lists.pharo.org> wrote:
>
>>
>>
>> ---------- Forwarded message ----------
>> From: Alidra Abdelghani <alidran...@yahoo.fr>
>> To: pharo-users@lists.pharo.org
>> Cc: "Stéphane Ducasse" <stephane.duca...@inria.fr>, farid arfi <
>> arf...@hotmail.com>
>> Bcc:
>> Date: Mon, 31 Jul 2017 01:38:58 +0200
>> Subject: Threads safety in Pharo
>> Hi,
>>
>> Somebody once evoked the problem of threads safety in Pharo. With a
>> friend of mine who is expert in formal methods and process scheduling, we
>> would like to have a look on it.
>> Does anyone knows a good document describing the problem of Pharo with
>> threads safety or at least any document that we can start with?
>>
>> Thanks in advance,
>> Abdelghani
>>
>>
>>
>>
>
>
> --
>
> Guille Polito
>
> Research Engineer
> French National Center for Scientific Research - *http://www.cnrs.fr*
> <http://www.cnrs.fr/>
>
>
> *Web:* *http://guillep.github.io* <http://guillep.github.io/>
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>
>
>
>

Reply via email to