On Thu Aug 24 22:51:27 2023 +0000, Yuxuan Shui wrote:
hmm, you are entirely right. now i wonder how microsoft does it. maybe the multiple owners bit is meaningful in some way. below is just **me thinking out loud:** so it seems to me the `transfer_ownership` process (let's call this the TO thread for brevity) have to be done in two steps, first it scans the list, find out who needs to be woken up, without actually waking them up. then it needs to detect if some thread has started acquiring the lock, in which case it should bail; if not, it updates the lock pointer to reflect the new tail, then wakes up the waiters and thus free the nodes. this means the waiter side needs to coordinate to let the TO thread know its intention to append to the list. and because of the problem you pointed out, this coordination has to be done through the lock ptr itself, because list node could be freed before we write into them. the easiest way is using the list_locked bit as a spin lock, which i did consider, but thought the potential of making releasing side block is bad. at least this would work as a last resort.
i guess this also means the waiter must update the tail (the lock ptr, we should name it something) before trying to update `tail->next`.