> 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 <marcospera...@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
> <marcospera...@apache.org> wrote:
>> Om perfect simo...
>>
>> I just checked it out..
>> great work. :-)
>>
>>
>> --
>> Marco Speranza <marcospera...@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
>>> <marcospera...@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 <marcospera...@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 <simonetrip...@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-unsubscr...@commons.apache.org
>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
