Le 13/08/2013 13:50, Gilles a écrit : > Hi. Hi Gilles,
> >> > [...] >> [...] >> >> <side rant>Historically, we did not care about thread-safety at all >> in [math], assuming the standard use case was *always* going to be >> one instance per thread. The statistics aggregators are an example >> where multithreaded access makes sense, but this is much more the >> exception than the rule in [math]. I would really like to get clear >> on which classes really need to be threadsafe themselves rather than >> blindly assuming that all do and insisting that everything be >> immutable so that we don't have to think about how to make things >> threadsafe.</side rant> >> > > We would be more able to advance if we consider that "threadsafe > and "immutable" are _not_ interchangeable. > > We have seen (in Commons Math also) that immutability can provide > thread-safety in a cheap way. Immutability is mostly easy to > implement when an object's fields are initialized with data that is > guaranteed to not be held by another object, and whose accessors > will forbid modification. Immutability is not used only for thread safety. It is an interesting property even for single threaded applications and more so for applications that are built from several layers developed by different teams (which is obviously the case for [math] as we only develop the lowest layer. Without immutability, developers at upper levels do not only have to know the API, they also have to known the gory details of *all* underlying levels and how the manage their input. Otherwise, they need to perform copies by themselves for defensive programming, and often forget to do so. > > Alois, it seems that "final" is (was?) useful for performance > reason. [But again, this would probably be noticeable only with > many allocations. Is there such a case for optimizer objects?] > > However, designing a class to be immutable is not always cheap. An > example is the combination that is the subject of this thread; here, > "costly" means: a lot of repetitive code lines[1], which could be > easily avoided by dropping immutability, without loosing anything > because: > 1. the code is _not_ threadsafe anyways (with or without "final"), > 2. the code could be made thread-safe, with or without "final". Yes, but this only a part 'and I think a small part) of the deal. I really think we should do it, even if it is costly from a development point of view, even for single threaded applications, just for the better safety it provides for upper levels. And yes, I know this is not sufficient to get completely safe code, but it is really a *big* step forward and helps developers of upper layers to concentrate on other things. > > Hence, I think that when the functionality is well circumscribed, > and it is easy to make everything "final", it's worth it. But when > it's not that easy, we should indeed not insist on it[2] without > 1. use-cases that show the need for multi-threaded usage of the > class, and > 2. providing proof that immutability does indeed bring thread-safety. I don't agree with 2, for the reasons above (we don't use immutability only for the sake of thread safety). best regards, Luc > > I still think that CM should care about multi-threading (reasons > detailed in other posts) but we should focus on tasks where the > developers can readily _measure_ the benefits rather than spend (a > lot of) time designing complex schemes which are not required by > common use-cases. > In addition to "stat", a few other CM areas where MT is of direct > application are: FFT, Genetic Algorithms, Machine-learning, ... > > > Regards, > Gilles > >> > [...] > > [1] Cf. diff (in recent commits of optimizer classes in package > "o.a.c.m.fitting.leastsquares") between mutable and immutable > versions of the code. > [2] Because we loose something on the "simplicity" side. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
