Re: why the last thread must sweep to check every slot again?

On 7/16/20 8:01 AM, Liu via Concurrency-interest wrote:
> 聛0聞2 聛0聞2 聛0聞2In jdk1.8,聛0聞2ConcurrentHashMap's transfer function is used to 
> resize, but there is a place I don隆炉t understand. see below.
> if (i <0 || i >= n || i + n >= nextn) {
>      int sc; if (finishing) {
>          nextTable =null; table = nextTab; sizeCtl = (n <<1) - (n >>>1); return; }
>      if (U.compareAndSwapInt(this, SIZECTL, sc =sizeCtl, sc -1)) {
>          if ((sc -2) !=resizeStamp(n) <<RESIZE_STAMP_SHIFT)
>              return; finishing = advance =true; i = n; // recheck before commit }
> }
> 聛0聞2 聛0聞2From the code above, the last thread to restore sizeCtl must 
> recheck every slot again. But in my opinion, when the last thread to 
> restore sizeCtl, every slot have been transfer to the new table 
> already. So why聛0聞2why the last thread must sweep to check every slot again?
>
Yes, this is a valid point; thanks. The post-scan was needed in a 
previous version, and could be removed. It does not trigger often enough 
to matter though, so is for now another minor tweak that might be 
included next time CHM is updated.

-Doug

_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest