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 21:40:02 GMT
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


Mime
View raw message