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 5508E95D4 for ; Sat, 3 Mar 2012 13:13:53 +0000 (UTC) Received: (qmail 19110 invoked by uid 500); 3 Mar 2012 13:13:52 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 19031 invoked by uid 500); 3 Mar 2012 13:13:52 -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 19023 invoked by uid 99); 3 Mar 2012 13:13:52 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 03 Mar 2012 13:13:52 +0000 Received: from localhost (HELO [192.168.0.4]) (127.0.0.1) (smtp-auth username marcosperanza, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Sat, 03 Mar 2012 13:13:52 +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 14:13:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <660081FA-732D-4CA5-BEFC-A5E6D457945E@apache.org> References: <7D559666-BDAF-4B0B-854B-E2CCF7B59165@apache.org> <55261764-7F6E-4DD5-BBFD-6CABF5940E89@apache.org> <8A601E86-5D6C-46C0-90F2-369907594D8E@apache.org> <40CCE98F-30AD-4CAB-A0D6-39CAFD48C86E@apache.org> <145825A5-3CD6-477A-8355-0845A2888741@apache.org> To: "Commons Developers List" X-Mailer: Apple Mail (2.1251.1) Morning Simo, my doubt is this: opening a synchronized block into handler = implementation on 'this', in my opinion is not enough, because the = method "CommonsGraph.synchronize()" returns a instance of the Proxy and = not an instance of handler. So an user cannot use the same "lock" in order to synchronize a 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 So my idea is to open synchronized block inside handler implementation = using the same Proxy instance that the method 'CommonsGraph.synchronize' = will return. Furthermore I'd like to modify the API by adding also the possibility = for the user to use an your own lock, in that way CommonsGraph.synchronize( G graph, Object lock ) WDYT? Finally only one question. I think that we should add some tests in = order to check the correct implementation of our multithrading = implementation. Do you think that we can use an external library in test scope? have a nice day -- Marco Speranza Google Code: http://code.google.com/u/marco.speranza79/ Il giorno 03/mar/2012, alle ore 13:50, Simone Tripodi ha scritto: > Good morning Marco, >=20 > I had the chance to have a deeper look at your yesterday's night work > and think your additions are good improvements - I just wonder if we > can replace the lock object with the handler itself, referencing > `this` instead. >=20 > Thoughts? >=20 > best and have a nice WE, > -Simo >=20 > http://people.apache.org/~simonetripodi/ > http://simonetripodi.livejournal.com/ > http://twitter.com/simonetripodi > http://www.99soft.org/ >=20 >=20 >=20 > On Sat, Mar 3, 2012 at 1:56 AM, Simone Tripodi = wrote: >> I saw the commit, please read comments inline. >> best, >> -Simo >>=20 >> http://people.apache.org/~simonetripodi/ >> http://simonetripodi.livejournal.com/ >> http://twitter.com/simonetripodi >> http://www.99soft.org/ >>=20 >>=20 >>=20 >> On Sat, Mar 3, 2012 at 1:40 AM, Marco Speranza = wrote: >>> Hi I fixed the problem using proxy/handler. >>>=20 >>> I put also a couple of tests. For do that I insert a test scoped = dependency to a library net.sourceforge.groboutils.groboutils-core >>>=20 >>> Ciao >>>=20 >>> -- >>> Marco Speranza >>> Google Code: http://code.google.com/u/marco.speranza79/ >>>=20 >>> Il giorno 03/mar/2012, alle ore 01:29, Simone Tripodi ha scritto: >>>=20 >>>> yes, what I didn't understand is how you would like to manage the >>>> iterators issue >>>>=20 >>>> sorry for the brevity but tonight I am getting crazy with at least = 3 >>>> other projects :D >>>>=20 >>>> -Simo >>>>=20 >>>> http://people.apache.org/~simonetripodi/ >>>> http://simonetripodi.livejournal.com/ >>>> http://twitter.com/simonetripodi >>>> http://www.99soft.org/ >>>>=20 >>>>=20 >>>>=20 >>>> On Sat, Mar 3, 2012 at 1:16 AM, Marco Speranza = wrote: >>>>> I think that we have to use the same patter of java Collections: a = wrapper of Graph/MutableGraph that use a synchronize block. >>>>>=20 >>>>> WDYT? >>>>>=20 >>>>> -- >>>>> Marco Speranza >>>>> Google Code: http://code.google.com/u/marco.speranza79/ >>>>>=20 >>>>> Il giorno 03/mar/2012, alle ore 01:10, Simone Tripodi ha scritto: >>>>>=20 >>>>>> OK now sounds better, thanks - how would you intend to fix it? >>>>>> TIA, >>>>>> -Simo >>>>>>=20 >>>>>> http://people.apache.org/~simonetripodi/ >>>>>> http://simonetripodi.livejournal.com/ >>>>>> http://twitter.com/simonetripodi >>>>>> http://www.99soft.org/ >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Sat, Mar 3, 2012 at 1:01 AM, Marco Speranza = wrote: >>>>>>>>>=20 >>>>>>>>> furthermore there is another problem: with handler is not = possible to use correctly synchronization block like this >>>>>>>>>=20 >>>>>>>>> =3D=3D=3D=3D >>>>>>>>> Graph g =3D CommonsGraph.synchronize(g_); >>>>>>>>> ... >>>>>>>>> synchronized(g) { >>>>>>>>> for ( BaseLabeledVertex v2 : g.getVertices() ) >>>>>>>>> { >>>>>>>>> // do somethings >>>>>>>>> } >>>>>>>>> } >>>>>>>>> =3D=3D=3D=3D >>>>>>>>=20 >>>>>>>> sorry I don't understand what you meant/intend to do >>>>>>>=20 >>>>>>> I'm trying to explain better. the method getVertices return an = Iterator. In a multi-thread environment you have to ensure that during = the 'for' execution the [graph] data structure remains consistent. >>>>>>> Also for java collection is the same = [http://docs.oracle.com/javase/6/docs/api/java/util/Collections.html#synch= ronizedCollection(java.util.Collection)] >>>>>>>=20 >>>>>>> So if we use a proxy/handler there is no way to "export" the = mutex/lock variable used into handler class. >>>>>>>=20 >>>>>>> In our CommonsGraph the variable this.lock is private and is = non possible to export out of the method, so the user can not utilize = the lock to synchronize his block. >>>>>>>=20 >>>>>>> =3D=3D=3D >>>>>>> public Object invoke( Object proxy, Method method, = Object[] args ) >>>>>>> throws Throwable >>>>>>> { >>>>>>> if ( synchronizedMethods.contains( method ) ) >>>>>>> { >>>>>>> try >>>>>>> { >>>>>>> synchronized ( this.lock ) >>>>>>> { >>>>>>> return method.invoke( = synchronizedMethods, args ); >>>>>>> } >>>>>>> } >>>>>>> catch ( InvocationTargetException e ) >>>>>>> { >>>>>>> throw e.getTargetException(); >>>>>>> } >>>>>>> } >>>>>>> return method.invoke( synchronizedMethods, args ); >>>>>>> } >>>>>>> =3D=3D=3D >>>>>>>=20 >>>>>>> ciao >>>>>>>=20 >>>>>>> -- >>>>>>> Marco Speranza >>>>>>> Google Code: http://code.google.com/u/marco.speranza79/ >>>>>>>=20 >>>>>>> Il giorno 03/mar/2012, alle ore 00:45, Simone Tripodi ha = scritto: >>>>>>>=20 >>>>>>>>> furthermore there is another problem: with handler is not = possible to use correctly synchronization block like this >>>>>>>>>=20 >>>>>>>>> =3D=3D=3D=3D >>>>>>>>> Graph g =3D CommonsGraph.synchronize(g_); >>>>>>>>> ... >>>>>>>>> synchronized(g) { >>>>>>>>> for ( BaseLabeledVertex v2 : g.getVertices() ) >>>>>>>>> { >>>>>>>>> // do somethings >>>>>>>>> } >>>>>>>>> } >>>>>>>>> =3D=3D=3D=3D >>>>>>>>=20 >>>>>>>> sorry I don't understand what you meant/intend to do >>>>>>>>=20 >>>>>>>>> I really think that a synchronized wrapper it's the best = solution. >>>>>>>>>=20 >>>>>>>>> WDYT? >>>>>>>>=20 >>>>>>>> they sucks because we have to keep them updated while , but if = there >>>>>>>> are not alternatives... >>>>>>>> -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 >>>=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