Primitive Queue<any T> considerations

[Vitaly Davidovich]

Yes, this is a good approach.

sent from my phone
On Nov 18, 2015 7:35 PM, "John Rose" <john.r.rose at oracle.com> wrote:

> On Nov 18, 2015, at 12:16 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
>
> Using David's example, say he wanted to have queue of nullable longs, which
> internally he'd store as Optional<long>.  But how does he specify in his
> generic class definition that when sizeof (Optional<T>) > word size that
> he'd like atomic access? This goes back to specialization selection, but
> has size constraint.
>
>
> It doesn't need specialization.  It can be expressed with a use-site
> keyword
> for atomicity, or (better) just for a suitable wrapper type.
>
> class MyQ<T> {
>    private optional<T>[] buf0;
>    private atomic<T>[] buf1;
>    private atomic<optional<T>>[] buf2;
>    ...
> }
>
> An atomic<T> of a naturally atomic type T can be bitwise identical
> to its underlying T.  For a larger T, the JVM will have to allocate
> mutex resources, but it is not required to allocate a mutex per field,
> so it is likely the resources will be amortizable (e.g., in the containing
> object header, split lock side table, etc., etc.).
>
>