> I think that we can create a class Graphs that has static methods to wrap > [graph] in a thread-safe way. > So the user can choose the preferred implementation.
Sorry but at first reading it was not clear to me what you meant, reading the second time I thought you maybe intended the <http://docs.oracle.com/javase/6/docs/api/java/util/Collections.html#synchronizedCollection(java.util.Collection)> related for [graph]? if yes, why should it be put in a separated class? the existing entry point sounds be more than enough for hosting that methods. Anyway, since I broke it I am going to fix it, I just need few minutes. best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Mar 2, 2012 at 9:19 PM, Simone Tripodi <simonetrip...@apache.org> wrote: > Hola Marco, > >> Yep I think that [graph] has to be not thread safe, because if a user uses >> [graph] in a not multi-thread environment the synchronization is not needed >> and the performance degrade. > > given the fact that myself at first place wouldn't ever use these data > structure in a production environment, how many chances we do have, in > the era of web applications, that users work in a single threaded > environment? > >> I think that we can create a class Graphs that has static methods to wrap >> [graph] in a thread-safe way. >> So the user can choose the preferred implementation. > > uhm, not sure this is the best pattern to apply :) > >> I'm working on a patch. If you agree I can create a patch to explain my idea. >> > > better rolling back the commit and mark classes not thread safe - I'll > create separated Concurrent* implementations. > > Thanks for reviewing! > -Simo > > http://people.apache.org/~simonetripodi/ > http://simonetripodi.livejournal.com/ > http://twitter.com/simonetripodi > http://www.99soft.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
