ср, 25 янв. 2023 г., 12:08 Stefan de Konink <stefan@konink.de>:
On Wednesday, January 25, 2023 10:05:36 AM CET, Andrew Randrianasulu wrote:
> Just for making things more clear: *I* added this unlock, not because I
> knew what I was doing but simply because yeah, it looked like this place
> might need it.
>
> In theory oicks protects shared resources, so one thread may leave
> object/variable around without worry another thread scheduled by kernel
> will overwrite it.
>
> But I do not know enough of details for carelessly altering locking like I
> did. So, Phyllis removed this line on my request, because, I reiterate, I
> put it there literally on a whim.

I think you did fix a bug at this place, and I wonder how total lock would
get unlocked (other than maybe time out?).


I guess we can scratch our collective head over this for some more  time, because IIRC Phyllis currently sleeping (hopefully).

I do not remember any simple way to trigger this codepath, but may be I'll rediscover something ....

sorry for being more clueless than everyone hoped.

--
Stefan