On 23.09.2013, at 15:46, Frank Shearar <[email protected]> wrote:
> On 23 September 2013 14:34, Max Leske <[email protected]> wrote: >> >> On 23.09.2013, at 15:20, Frank Shearar <[email protected]> wrote: >> >>> On 23 September 2013 14:17, Nicolas Cellier >>> <[email protected]> wrote: >>>> Here is my 100% personal opinion: >>>> >>>> I don't like the copyShuffle. >>>> To me, the rules are quite clear: >>>> sort shuffle reverse etc... -> perform modification in place >>>> sorted shuffled reversed etc... -> answer a copy >>>> I hope the methods comments are clear. Does PBE tells about these >>>> conventions? It would be a good thing. >>>> >>>> And I don't like to have mutexes in base library, the less we have, the >>>> better. >>>> If a user is going to modify the same object concurrently, he/she takes >>>> care >>>> of mutual exclusion. >>> >>> Especially since locks don't compose. If you _really_ cared about >>> accessing something concurrently, you'd share immutable data >>> structures. >> >> I don't quite follow. Could you elaborate? > > Hopefully it's uncontroversial to assert that locks don't compose. > > If you only ever have one thread of execution, you don't have any > concurrency issues, and locks serve no purpose. > > If you do have multiple threads of execution, then you have a few > choices for sharing data: > * you can use a lock around mutable data (but lock-using blocks of > code don't compose, so you end up with loads of bugs or deadlocks or > nests of locks, or all of the above) > * you can share a _copy_ of data. > > In the latter case, you can share an actual copy, or share a pointer > to a structure that can't change. If it can't change, you can't have a > reader accidentally reading something from a structure halfway through > the writer writing to it. > > Sharing some immutable chunk of state lets you save the memory taken > up by a copy, but also prevents all the race condition things you > usually get with shared mutable state. > > frank Thanks Frank, I get it now. And I agree. > > >>> frank >>> >>>> 2013/9/23 Max Leske <[email protected]> >>>>> >>>>> Sven suggested posting this on the list for discussion, so here you go: >>>>> >>>>> Maybe this should be discussed on the list, your are going to break API. >>>>> >>>>> Note that there is also #sort and #sorted with similar copy behavior. >>>>> >>>>> Also, I am not sure that basic operations should use mutexes to protect >>>>> themselves by default: there is a cost when you are a single threaded >>>>> user. >>>>> Even in Java there are synchronized and non-synchronized versions of >>>>> collections. IMHO, the protection should happen in your app, and basic >>>>> collections do not have to be thread safe. >>>>> >>>>> Sven >>>>> >>>>> #shuffle does not use Collection>>mutexForPicking as other users of >>>>> #randomForPicking demonstrate. This can lead to race conditions (found in >>>>> our application). >>>>> >>>>> In addition, there are now #shuffle, #shuffled, #shuffleBy: and >>>>> #shuffledBy: where #shuffled and #shuffledBy: shuffle a copy and answers >>>>> that. This is very confusing. >>>>> >>>>> I propose a fix where #shuffled and #shuffledBy: are renamed to >>>>> #copyShuffle and #copyShuffledBy: and moved to the "copying" protocol. >>>>> #shuffle and #copyShuffle will use the mutex to prevent race conditions. >>>> >>>> >>> >> >> >
