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