> 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:alidran...@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 > > >> > > >> > > >> > > > > > >
