JDK's BitSet is not, but there is an implementation in some Apache
licensed project.
On 14 January 2012 20:13, Manik Surtani <manik(a)jboss.org> wrote:
A BitSet ought to be thread safe too, right? Otherwise doing bit
masks manually and then a compare-and-set on a long field to hold the final value would
make it thread safe. :)
On 14 Jan 2012, at 18:08, Dan Berindei wrote:
> Good catch Manik! I just copied the approach from
> ClusteredGetResponseFilter and I didn't think too much about
> performance issues.
>
> Bela, the BitSet approach sounds a little better than a simple counter
> from a debugging perspective. But I think we're also missing some
> synchronization at the moment, and with the counter approach could be
> made thread-safe with minimal overhead by using an AtomicInteger. I
> assume using a counter only is safe (i.e. RspFilter.isAcceptable()
> will never be called twice for the same target).
>
> ClusteredGetResponseFilter could probably use the same treatment,
> except the targets list is quite small so we can search in the list
> directly instead of creating a HashSet with the same contents.
>
> Cheers
> Dan
>
>
> On Sat, Jan 14, 2012 at 4:06 PM, Bela Ban <bban(a)redhat.com> wrote:
>> Another implementation could take the current view, and create a BitSet
>> with the size being the length of the view, and every bit corresponds to
>> the position of a member in the view, e.g.:
>> V1={A,B,C,D,E,F}, bitset={0,0,1,0,1,1} means that responses have been
>> received from C, E and F.
>>
>> On 1/13/12 8:20 PM, Manik Surtani wrote:
>>> Looking at IgnoreExtraResponsesValidityFilter - this seems to be a
scalability issue! It seems to copy a set of every address in the cluster and gradually
remove entries as responses come in. Isn't this a scalability issue? Since -
assuming a large cluster - for every prepare command, we create a collection, copy into it
the entire list of addresses (think hundreds of nodes x hundreds of concurrent threads)
only to "count down" on the responses. I'm almost certain there is a better
way to do this! :) Maybe even maintain a shared list of members (updated whenever there
is a view change) to test for responses from non-members, a counter, and assume that
members don't respond to the same request more than once?
>>>
>>> Cheers
>>> Manik
>>> --
>>> Manik Surtani
>>> manik(a)jboss.org
>>>
twitter.com/maniksurtani
>>>
>>> Lead, Infinispan
>>>
http://www.infinispan.org
>>
>> --
>> Bela Ban
>> Lead JGroups (
http://www.jgroups.org)
>> JBoss / Red Hat
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev