commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marco Speranza <marcospera...@apache.org>
Subject Re: [Graph] Test problems after last commit
Date Fri, 02 Mar 2012 23:33:33 GMT
> 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. 
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
       }
  }
====

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. 

WDYT?

--
Marco Speranza <marcosperanza@apache.org>
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...
> 
> 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:40 PM, Marco Speranza
> <marcosperanza@apache.org> wrote:
>> Om perfect simo...
>> 
>> I just checked it out..
>> great work. :-)
>> 
>> 
>> --
>> Marco Speranza <marcosperanza@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
>>> <marcosperanza@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 <marcosperanza@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 <simonetripodi@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-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


Mime
View raw message