Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
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 <marcosperanza@apache.org>
In-Reply-To: 
 <CAAqLGLPLRF81DWWCej66TRFTw0p_FtWYFrf-NhtOARPp2ot7hw@mail.gmail.com>
Date: Sat, 3 Mar 2012 01:01:48 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <40CCE98F-30AD-4CAB-A0D6-39CAFD48C86E@apache.org>
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>
To: "Commons Developers List" <dev@commons.apache.org>

>>=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

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.=20
Also for java collection is the same =
[http://docs.oracle.com/javase/6/docs/api/java/util/Collections.html#synch=
ronizedCollection(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.

=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

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
>>=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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org