Om perfect simo... I just checked it out.. great work. :-)
-- Marco Speranza <marcospera...@apache.org> Google Code: http://code.google.com/u/marco.speranza79/ Il giorno 02/mar/2012, alle ore 22:36, Simone Tripodi ha scritto: > I would have preferred a Concurrent* version for our data structures, > but I can happily live with the synchronized version even if not the > top. > > an initial quick implementation is done and already on SVN - I took > few minutes to make it - so please check it out and and feel free to > add improvements, I am still working on it. > > 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 10:22 PM, Marco Speranza > <marcospera...@apache.org> wrote: >>> 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]? >> >> Yes Simo... I meant just what. I think that this patter is the best choice. >> >>> if yes, why should it be put in a separated class? the existing entry >>> point sounds be more than enough for hosting that methods. >> >> you are right so if you agreed I can work on that. >> >> Ciao >> >> >> -- >> Marco Speranza <marcospera...@apache.org> >> Google Code: http://code.google.com/u/marco.speranza79/ >> >> Il giorno 02/mar/2012, alle ore 21:34, Simone Tripodi ha scritto: >> >>>> 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 >>> >> >> >> --------------------------------------------------------------------- >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
