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