Return-Path: X-Original-To: apmail-commons-dev-archive@www.apache.org Delivered-To: apmail-commons-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 80E4A9225 for ; Fri, 2 Mar 2012 23:33:38 +0000 (UTC) Received: (qmail 97001 invoked by uid 500); 2 Mar 2012 23:33:38 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 96900 invoked by uid 500); 2 Mar 2012 23:33:38 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 96892 invoked by uid 99); 2 Mar 2012 23:33:37 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Mar 2012 23:33:37 +0000 Received: from localhost (HELO [10.0.1.3]) (127.0.0.1) (smtp-auth username marcosperanza, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Mar 2012 23:33:37 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) Subject: Re: [Graph] Test problems after last commit From: Marco Speranza In-Reply-To: Date: Sat, 3 Mar 2012 00:33:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8A601E86-5D6C-46C0-90F2-369907594D8E@apache.org> References: <7D559666-BDAF-4B0B-854B-E2CCF7B59165@apache.org> <55261764-7F6E-4DD5-BBFD-6CABF5940E89@apache.org> To: "Commons Developers List" X-Mailer: Apple Mail (2.1251.1) > uhm I am not really satisfied, the checks and the proxy handler > decrease performances, that is why I asked you to improve the impl - > just implementing synchronized wrappers would be more performant, but > would make boring maintaining all data structures in synch with future > modifications... hi simo. yes the proxy and the handler decrease performances.=20 furthermore there is another problem: with handler is not possible to = use correctly synchronization block like this =3D=3D=3D=3D Graph g =3D CommonsGraph.synchronize(g_); ... synchronized(g) { for ( BaseLabeledVertex v2 : g.getVertices() ) { // do somethings } } =3D=3D=3D=3D that's because the lock is a private variable of proxyHandler. This is = strongly needed to manage in the right way the mutex and avoid = ConcurrentModification. I really think that a synchronized wrapper it's the best solution.=20 WDYT? -- Marco Speranza Google Code: http://code.google.com/u/marco.speranza79/ Il giorno 02/mar/2012, alle ore 23:07, Simone Tripodi ha scritto: > uhm I am not really satisfied, the checks and the proxy handler > decrease performances, that is why I asked you to improve the impl - > just implementing synchronized wrappers would be more performant, but > would make boring maintaining all data structures in synch with future > modifications... >=20 > best, > -Simo >=20 > http://people.apache.org/~simonetripodi/ > http://simonetripodi.livejournal.com/ > http://twitter.com/simonetripodi > http://www.99soft.org/ >=20 >=20 >=20 > On Fri, Mar 2, 2012 at 10:40 PM, Marco Speranza > wrote: >> Om perfect simo... >>=20 >> I just checked it out.. >> great work. :-) >>=20 >>=20 >> -- >> Marco Speranza >> Google Code: http://code.google.com/u/marco.speranza79/ >>=20 >> Il giorno 02/mar/2012, alle ore 22:36, Simone Tripodi ha scritto: >>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> best, >>> -Simo >>>=20 >>> http://people.apache.org/~simonetripodi/ >>> http://simonetripodi.livejournal.com/ >>> http://twitter.com/simonetripodi >>> http://www.99soft.org/ >>>=20 >>>=20 >>>=20 >>> On Fri, Mar 2, 2012 at 10:22 PM, Marco Speranza >>> 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 >>>>> = >>>>> related for [graph]? >>>>=20 >>>> Yes Simo... I meant just what. I think that this patter is the best = choice. >>>>=20 >>>>> if yes, why should it be put in a separated class? the existing = entry >>>>> point sounds be more than enough for hosting that methods. >>>>=20 >>>> you are right so if you agreed I can work on that. >>>>=20 >>>> Ciao >>>>=20 >>>>=20 >>>> -- >>>> Marco Speranza >>>> Google Code: http://code.google.com/u/marco.speranza79/ >>>>=20 >>>> Il giorno 02/mar/2012, alle ore 21:34, Simone Tripodi ha scritto: >>>>=20 >>>>>> 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. >>>>>=20 >>>>> Sorry but at first reading it was not clear to me what you meant, >>>>> reading the second time I thought you maybe intended the >>>>> = >>>>> related for [graph]? >>>>>=20 >>>>> if yes, why should it be put in a separated class? the existing = entry >>>>> point sounds be more than enough for hosting that methods. >>>>>=20 >>>>> Anyway, since I broke it I am going to fix it, I just need few = minutes. >>>>>=20 >>>>> best, >>>>> -Simo >>>>>=20 >>>>> http://people.apache.org/~simonetripodi/ >>>>> http://simonetripodi.livejournal.com/ >>>>> http://twitter.com/simonetripodi >>>>> http://www.99soft.org/ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Fri, Mar 2, 2012 at 9:19 PM, Simone Tripodi = wrote: >>>>>> Hola Marco, >>>>>>=20 >>>>>>> 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. >>>>>>=20 >>>>>> 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? >>>>>>=20 >>>>>>> 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. >>>>>>=20 >>>>>> uhm, not sure this is the best pattern to apply :) >>>>>>=20 >>>>>>> I'm working on a patch. If you agree I can create a patch to = explain my idea. >>>>>>>=20 >>>>>>=20 >>>>>> better rolling back the commit and mark classes not thread safe - = I'll >>>>>> create separated Concurrent* implementations. >>>>>>=20 >>>>>> Thanks for reviewing! >>>>>> -Simo >>>>>>=20 >>>>>> http://people.apache.org/~simonetripodi/ >>>>>> http://simonetripodi.livejournal.com/ >>>>>> http://twitter.com/simonetripodi >>>>>> http://www.99soft.org/ >>>>>=20 >>>>> = --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >>>>> For additional commands, e-mail: dev-help@commons.apache.org >>>>>=20 >>>>=20 >>>>=20 >>>> = --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >>>> For additional commands, e-mail: dev-help@commons.apache.org >>>>=20 >>>=20 >>> = --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >>> For additional commands, e-mail: dev-help@commons.apache.org >>>=20 >>=20 >>=20 >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >> For additional commands, e-mail: dev-help@commons.apache.org >>=20 >=20 > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org > For additional commands, e-mail: dev-help@commons.apache.org >=20 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org