Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Received-SPF: pass (google.com: domain of jcarman@carmanconsulting.com
 designates 10.52.69.100 as permitted sender) client-ip=10.52.69.100;
MIME-Version: 1.0
In-Reply-To: 
 <CAAqLGLMtR5iVeM__hjA8HN+c8L-O1+8=XJq_Fy12mae3aCjDrw@mail.gmail.com>
References: <7D559666-BDAF-4B0B-854B-E2CCF7B59165@apache.org>
	<CAAqLGLPP8prDXT3OZhz_Q4gxYvku89YTqfp1DXc=M8v=GgO=pg@mail.gmail.com>
	<FE64CBBE-C943-48E8-B371-E35632263350@apache.org>
	<CAAqLGLOKw8COdHcSqy=qp6tAp0omm6eukfk51L2h9cxft31tqw@mail.gmail.com>
	<B918E82D-0D25-4191-88C8-E1667ADECEC2@apache.org>
	<CAAqLGLOW-Sob2MTs4WJzbTSTwbZtCaoNipB52Zp9+0JQGD9dEQ@mail.gmail.com>
	<CAAqLGLOyQXQcdegSE3RFy10SnFpbtH4sFQb+0ppcRyuR0YOMww@mail.gmail.com>
	<D9411435-7F72-4B9C-9653-06C51723E54E@apache.org>
	<CAAqLGLNkFBtjW7Jga8uLfZgPHAQijn8TvkKgK6GsRdSSR9g+JQ@mail.gmail.com>
	<55261764-7F6E-4DD5-BBFD-6CABF5940E89@apache.org>
	<CAAqLGLNCWoZszGnY8kSkd-Sa0Na8TY8_eWsKaoSZf1vDc=JYDg@mail.gmail.com>
	<8A601E86-5D6C-46C0-90F2-369907594D8E@apache.org>
	<CAAqLGLPLRF81DWWCej66TRFTw0p_FtWYFrf-NhtOARPp2ot7hw@mail.gmail.com>
	<40CCE98F-30AD-4CAB-A0D6-39CAFD48C86E@apache.org>
	<CAAqLGLN6vGPrOsFmzOVcF=PW-3AkQ8u7xBVyaeBEfBDT7PVPgA@mail.gmail.com>
	<145825A5-3CD6-477A-8355-0845A2888741@apache.org>
	<AF4C2904-73D3-474B-8ED9-022CE989685B@apache.org>
	<CAAqLGLPnsAnMnpP8f7AbgLXQqdZeYazLTohAxVhyjVq3mF2uqA@mail.gmail.com>
	<CAAqLGLNQJXJBQBjL-CUUd4b7YDaf4VaZJ9M-AFpVDLCKTzQUmQ@mail.gmail.com>
	<660081FA-732D-4CA5-BEFC-A5E6D457945E@apache.org>
	<CAAqLGLMtR5iVeM__hjA8HN+c8L-O1+8=XJq_Fy12mae3aCjDrw@mail.gmail.com>
Date: Sat, 3 Mar 2012 08:40:07 -0500
Message-ID: 
 <CALznzY6EFOA6aOhhmAV-6zB7hegNe_JNcQC+acoUsF5+wjz=rA@mail.gmail.com>
Subject: Re: [Graph] Test problems after last commit
From: James Carman <jcarman@carmanconsulting.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=20cf307cff00d7b0d504ba56d4dc

--20cf307cff00d7b0d504ba56d4dc
Content-Type: text/plain; charset=ISO-8859-1

I think a read/write lock might help.  Reads only need to be synchronized
around writes.  They don't have to be synchronized with one another.
On Mar 3, 2012 8:35 AM, "Simone Tripodi" <simonetripodi@apache.org> wrote:

> Hola Marco,
>
> > 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.
>
> true, but *all* methods executions (synchronized and not) are
> performed inside the handler, contained in the proxy instance anyway.
>
> So an user cannot use the same "lock"  in order to synchronize a block
> like this:
>
> ====
> Graph g = CommonsGraph.synchronize(g_);
>   ...
>  synchronized(g) {
>     for ( BaseLabeledVertex v2 : g.getVertices() )
>     {
>         // do somethings
>     }
>  }
> ====
>
> I am not sure we can do much more of what we've already done, for that
> situation: the snippet below mixes the *data structure*
> synchronization with the business logic performed outside.
>
> > 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 )
>
> I have not clear which benefit you want to obtain with that - looks at
> Collections#synchronized* methods and see that the separation of
> concerns in clear.
>
> > 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?
>
> Sure that we can, the only issue we have is that GroboUtils is not in
> the central repo, adding the external repository would make not easy
> having the component released.
>
> best,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Sat, Mar 3, 2012 at 2:13 PM, Marco Speranza <marcosperanza@apache.org>
> wrote:
> > 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:
> >
> > ====
> > Graph g = CommonsGraph.synchronize(g_);
> >    ...
> >  synchronized(g) {
> >      for ( BaseLabeledVertex v2 : g.getVertices() )
> >      {
> >          // do somethings
> >      }
> >  }
> > ====
> >
> > 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 <marcosperanza@apache.org>
> > 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,
> >>
> >> 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.
> >>
> >> Thoughts?
> >>
> >> best and have a nice WE,
> >> -Simo
> >>
> >> http://people.apache.org/~simonetripodi/
> >> http://simonetripodi.livejournal.com/
> >> http://twitter.com/simonetripodi
> >> http://www.99soft.org/
> >>
> >>
> >>
> >> On Sat, Mar 3, 2012 at 1:56 AM, Simone Tripodi <
> simonetripodi@apache.org> wrote:
> >>> I saw the commit, please read comments inline.
> >>> best,
> >>> -Simo
> >>>
> >>> http://people.apache.org/~simonetripodi/
> >>> http://simonetripodi.livejournal.com/
> >>> http://twitter.com/simonetripodi
> >>> http://www.99soft.org/
> >>>
> >>>
> >>>
> >>> On Sat, Mar 3, 2012 at 1:40 AM, Marco Speranza <
> marcosperanza@apache.org> wrote:
> >>>> Hi I fixed the problem using proxy/handler.
> >>>>
> >>>> I put also a couple of tests. For do that I insert a test scoped
> dependency to a library net.sourceforge.groboutils.groboutils-core
> >>>>
> >>>> Ciao
> >>>>
> >>>> --
> >>>> Marco Speranza <marcosperanza@apache.org>
> >>>> Google Code: http://code.google.com/u/marco.speranza79/
> >>>>
> >>>> Il giorno 03/mar/2012, alle ore 01:29, Simone Tripodi ha scritto:
> >>>>
> >>>>> yes, what I didn't understand is how you would like to manage the
> >>>>> iterators issue
> >>>>>
> >>>>> sorry for the brevity but tonight I am getting crazy with at least 3
> >>>>> other projects :D
> >>>>>
> >>>>> -Simo
> >>>>>
> >>>>> http://people.apache.org/~simonetripodi/
> >>>>> http://simonetripodi.livejournal.com/
> >>>>> http://twitter.com/simonetripodi
> >>>>> http://www.99soft.org/
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Sat, Mar 3, 2012 at 1:16 AM, Marco Speranza <
> marcosperanza@apache.org> wrote:
> >>>>>> I think that we have to use the same patter of java Collections: a
> wrapper of Graph/MutableGraph that use a synchronize block.
> >>>>>>
> >>>>>> WDYT?
> >>>>>>
> >>>>>> --
> >>>>>> Marco Speranza <marcosperanza@apache.org>
> >>>>>> Google Code: http://code.google.com/u/marco.speranza79/
> >>>>>>
> >>>>>> Il giorno 03/mar/2012, alle ore 01:10, Simone Tripodi ha scritto:
> >>>>>>
> >>>>>>> OK now sounds better, thanks - how would you intend to fix it?
> >>>>>>> TIA,
> >>>>>>> -Simo
> >>>>>>>
> >>>>>>> http://people.apache.org/~simonetripodi/
> >>>>>>> http://simonetripodi.livejournal.com/
> >>>>>>> http://twitter.com/simonetripodi
> >>>>>>> http://www.99soft.org/
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Sat, Mar 3, 2012 at 1:01 AM, Marco Speranza <
> marcosperanza@apache.org> wrote:
> >>>>>>>>>>
> >>>>>>>>>> furthermore there is another problem: with handler is not
> possible to use correctly synchronization block like this
> >>>>>>>>>>
> >>>>>>>>>> ====
> >>>>>>>>>> Graph g = CommonsGraph.synchronize(g_);
> >>>>>>>>>>     ...
> >>>>>>>>>>  synchronized(g) {
> >>>>>>>>>>       for ( BaseLabeledVertex v2 : g.getVertices() )
> >>>>>>>>>>       {
> >>>>>>>>>>           // do somethings
> >>>>>>>>>>       }
> >>>>>>>>>>  }
> >>>>>>>>>> ====
> >>>>>>>>>
> >>>>>>>>> sorry I don't understand what you meant/intend to do
> >>>>>>>>
> >>>>>>>> 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#synchronizedCollection(java.util.Collection)
> ]
> >>>>>>>>
> >>>>>>>> So if we use a proxy/handler there is no way to "export" the
> mutex/lock variable used into handler class.
> >>>>>>>>
> >>>>>>>> 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.
> >>>>>>>>
> >>>>>>>> ===
> >>>>>>>>        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 );
> >>>>>>>>        }
> >>>>>>>> ===
> >>>>>>>>
> >>>>>>>> ciao
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Marco Speranza <marcosperanza@apache.org>
> >>>>>>>> Google Code: http://code.google.com/u/marco.speranza79/
> >>>>>>>>
> >>>>>>>> Il giorno 03/mar/2012, alle ore 00:45, Simone Tripodi ha scritto:
> >>>>>>>>
> >>>>>>>>>> furthermore there is another problem: with handler is not
> possible to use correctly synchronization block like this
> >>>>>>>>>>
> >>>>>>>>>> ====
> >>>>>>>>>> Graph g = CommonsGraph.synchronize(g_);
> >>>>>>>>>>     ...
> >>>>>>>>>>  synchronized(g) {
> >>>>>>>>>>       for ( BaseLabeledVertex v2 : g.getVertices() )
> >>>>>>>>>>       {
> >>>>>>>>>>           // do somethings
> >>>>>>>>>>       }
> >>>>>>>>>>  }
> >>>>>>>>>> ====
> >>>>>>>>>
> >>>>>>>>> sorry I don't understand what you meant/intend to do
> >>>>>>>>>
> >>>>>>>>>> I really think that a synchronized wrapper it's the best
> solution.
> >>>>>>>>>>
> >>>>>>>>>> WDYT?
> >>>>>>>>>
> >>>>>>>>> they sucks because we have to keep them updated while , but if
> there
> >>>>>>>>> are not alternatives...
> >>>>>>>>> -Simo
> >>>>>>>>>
> >>>>>>>>> http://people.apache.org/~simonetripodi/
> >>>>>>>>> http://simonetripodi.livejournal.com/
> >>>>>>>>> http://twitter.com/simonetripodi
> >>>>>>>>> http://www.99soft.org/
> >>>>>>>>>
> >>>>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

--20cf307cff00d7b0d504ba56d4dc--