Suerly we can add a Critics Rule trying to detect the invalid pattern. On Fri, Aug 11, 2017 at 10:39 AM, monty <mon...@programmer.net> wrote:
> > Sent: Friday, August 11, 2017 at 6:36 AM > > From: "Denis Kudriashov" <dionisi...@gmail.com> > > To: "Any question about pharo is welcome" <pharo-users@lists.pharo.org> > > Subject: Re: [Pharo-users] Thread-safe initialization of class state > (was Re: Threads safety in Pharo) > > > > What package you explore? I not find fileTypes method in Pharo 7. > > Like I said, it's a hypothetical example. But I'm sure you could find > similar examples of unsafe class state initialization in the image and in > popular libraries. > > > 2017-08-11 8:53 GMT+02:00 monty <mon...@programmer.net[mailto: > mon...@programmer.net]>:Here's a hypothetical broken class method that > does lazy initialization of a class inst var: > > > > fileTypes > > fileTypes ifNil: [ > > fileTypes := Dictionary new. > > fileTypes > > at: 'txt' put: 'Text File'; > > at: 'html' put: 'Web Page'; > > at: 'pdf' put: 'Portable Document Format File'; > > at: 'doc' put: 'Microsoft Word Document']. > > ^ fileTypes. > > > > Because the assignment is done first and the initialization is done > after with a cascade of interruptable sends of #at:put:, there's a window > after the assignment where 'fileTypes' is not nil but also not fully > initialized--a race condition. > > > > The fix is simple. Do the initialization before the atomic assignment > takes place, so the var is only ever bound to nil or a fully initialized > object: > > > > fileTypes > > fileTypes ifNil: [ > > fileTypes := > > Dictionary new > > at: 'txt' put: 'Text File'; > > at: 'html' put: 'Web Page'; > > at: 'pdf' put: 'Portable Document Format > File'; > > at: 'doc' put: 'Microsoft Word Document'; > > yourself]. > > ^ fileTypes. > > > > The fixed code is still vulnerable to duplicate initialization, because > the initialization sequence is interruptable and 'fileTypes' is nil during > it, but as long as the initialization is cheap enough, has no side effects > that restrict how often it can be done, and it's enough that the > initialized objects are equal (but not identical), that's OK. > > > > If it's too complex for a single statement, you can use a temp vars or > put it in a separate factory method: > > > > fileTypes > > fileTypes ifNil: [ > > fileTypes := self newFileTypes]. > > ^ fileTypes. > > > > Similar precautions (given how easy) might as well be taken with > explicit initialization of class state too. Of course if the object is > mutated later (in other methods), then Mutexes or other constructs are > needed to guard access. But for immutable class state, ensuring > initialization is done before assignment should be enough. > > > > > Sent: Tuesday, August 01, 2017 at 7:36 AM > > > From: "Stephane Ducasse" <stepharo.s...@gmail.com[mailto: > stepharo.s...@gmail.com]> > > > To: "Any question about pharo is welcome" <pharo-users@lists.pharo.org > [mailto:pharo-users@lists.pharo.org]> > > > Subject: Re: [Pharo-users] Threads safety in Pharo > > > > > > I would love to have an analysis of assumptions made in some code. > > > Because my impression is that the concurrent code is sometimes defined > > > knowing the underlying logic of scheduler and this is not good. > > > As I said to abdel privately in french it would be great to start from > > > my french squeak book (Yes I wrote one long time ago) chapter on > > > concurrent programming and turn it into a pharo chapter. > > > > > > Stef > > > > > > On Tue, Aug 1, 2017 at 1:31 PM, Ben Coman <b...@openinworld.com[mailto: > b...@openinworld.com]> wrote: > > > > Not sure I'll have what you're looking for, but to start, do you mean > > > > Pharo's green threads or vm native threads? > > > > cheers -ben > > > > > > > > On Mon, Jul 31, 2017 at 7:38 AM, Alidra Abdelghani via Pharo-users > > > > <pharo-users@lists.pharo.org[mailto:pharo-users@lists.pharo.org]> > wrote: > > > >> > > > >> > > > >> > > > >> ---------- Forwarded message ---------- > > > >> From: Alidra Abdelghani <alidran...@yahoo.fr[mailto:al > idran...@yahoo.fr]> > > > >> To: pharo-users@lists.pharo.org[mailto:pharo-users@lists.pharo.org] > > > >> Cc: "Stéphane Ducasse" <stephane.duca...@inria.fr[mailto: > stephane.duca...@inria.fr]>, farid arfi > > > >> <arf...@hotmail.com[mailto: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 > > > >> > > > >> > > > >> > > > > > > > > > > >
