[Pharo-dev] 11635: Race condition in SequenceableCollection>>shuffle

Max Leske maxleske at gmail.com
Wed Oct 30 08:55:06 EDT 2013

Name: SLICE-Issue-11635-Race-condition-in-SequenceableCollectionshuffle-MaxLeske.2
Author: MaxLeske
Time: 30 October 2013, 1:41:57.198092 pm
UUID: c3d51645-7e81-4997-b74c-545bf7ef60b0
Dependencies: Collections-Abstract-MaxLeske.231, Collections-Unordered-MaxLeske.175

made changes as detailed on the mailing list

* shuffle
    ^ self shuffleBy: Random new
* shuffled
    ^ self copy shuffle
* removed #shuffledBy:
* Matrix uses #shuffleBy:  (on an explicit copy) instead of #shuffledBy:

On 01.10.2013, at 17:06, Henrik Johansen <henrik.s.johansen at veloxit.no> wrote:

> On Sep 28, 2013, at 10:59 , Max Leske <maxleske at gmail.com> wrote:
>> Thanks for the feedback guys.
>> Based on the discussion I propose a different set of changes:
>> 1.
>> shuffle
>> 	^ self shuffleBy: Random new
>> 2.
>> shuffled
>> 	^ self copy shuffle
>> 3. remove #shuffledBy: (if you're specific enough to use a custom Random instance you can also create a copy of the collection yourself if you want to)
>> I leave the matter of renaming the methods for further discussion. Personally I'm for more intention revealing selectors; I quite like #shuffle and #shuffleInPlace. If we can agree on a different naming scheme we should then apply it to other methods aswell of course (e.g. #sort, #sortInPlace).
>> Also open for discussion is the use of Collection>>randomForPicking and Collection>>mutexForPicking in other methods (such as #atRandom). I think it shouldn't be too big a problem to make those methods use individual Random instances and to remove the two class variables from Collection.
>> Cheers,
>> Max
> +1 from me on all three suggestions, as you might guess. :)
> As for #atRandom using Random new, the performance hit and seed quality would be much greater concerns, as the Random instance would only be used once per invocation.
> At this point in time there's no good alternatives to the current approach, but renaming the mutex/shared variable to reflect its singular use would be one possible improvement, I guess.
> Cheers,
> Henry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131030/cae2ac20/attachment-0002.html>

More information about the Pharo-dev mailing list