On 23 September 2013 14:34, Max Leske <maxleske@gmail.com> wrote:
On 23.09.2013, at 15:20, Frank Shearar <frank.shearar@gmail.com> wrote:
On 23 September 2013 14:17, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> 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 <maxleske@gmail.com>
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.