Primitive Queue<any T> considerations
richard.warburton at gmail.com
Wed Nov 18 14:24:58 UTC 2015
We are using the SpscArrayQueue (extends Queue<T>) from JCTools quite often
> in our library which exploits null as an indicator if the queue is full or
> not. However, this won't work in case of a Queue<any T> because for
> primitives, zero is a valid value.
> I see two options:
> - use wider primitive and atomics-acessible types: byte -> int, char ->
> int, short -> int, int -> long, float -> long, double -> 2 slots long and
> long -> 2 slots of long
> - don't use fast-flow and go back to producer-consumer index comparison.
> In either case, the internals and the usage have to be changed drastically,
> i.e., switch to AtomicLongArray, how to indicate the queue is actually
> empty when calling poll(), etc. Perhaps a new queue interface is necessary
> where poll returns a boolean indicator and calls a Consumer if the data is
> The examples I saw regarding valhalla showed List<any T> where I'd guess
> the internals of the ArrayList can be altered in a straightforward manner
> but I don't see how this could happen if the algorithm itself has to change
> based on what primitive T is.
> What are the plans for supporting such kind of specializations?
As Vitaly says you can have a value type that represents presence/absence
in your backing array.
Another option is having a "missing" value. This is the approach that I use
when writing/using primitive collections. There always seems to be a number
value that you can using to represent a missing element whenever I've used
primitive specialized collections. That missing value can be used where
null is used for reference types.
.NET has a "default(T)" construct where default some value is constructed
for a type, eg 0 for primitives, null for references which can used as a
missing value or as a way to initialise backing arrays.
More information about the valhalla-dev