[Python-Dev] deja-vu .. python locking

Martin Devera devik at cdi.cz
Mon Sep 18 17:06:47 CEST 2006


Martin v. Löwis wrote:
> Martin Devera schrieb:
>> RCU like locking
>>   Solution I have in mind is similar to RCU. In Python we have quiscent
>>   state - when a thread returns to main loop of interpreter.
> 
> There might be a terminology problem here. RCU is read-copy-update,
> right? I fail to see the copy (copy data structure to be modified)
> and update (replace original pointer with pointer to copy) part.
> Do this play a role in that scheme? If so, what specific structure
> is copied for, say, a list or a dict?
> 
> This confusion makes it very difficult for me to understand your
> proposal, so I can't comment much on it. If you think it could work,
> just go ahead and create an implementation.

It is why I used a word "similar". I see the similarity in a way to archieve
safe "delete" phase of RCU. Probably I selected bad title for the text. It
is because I was reading about RCU implementation in Linux kernel and
I discovered that the idea of postponing critical code to some safe point in
future might work in Python interpreter.

So that you are right. It is not RCU. It only uses similar technique as RCU
uses for free-ing old copy of data.

It is based on assumption that an object is typicaly used by single thread. You
must lock it anyway just for case if another thread steps on it. The idea is
that each object is "owned" by a thread. Owner can use its objects without
locking. If a thread wants to use foreign object then it has to wait for owning
thread to go to some safe place (out of interpreter, into LOCK of other object..).
It is done by per-thread lock and it is neccessary because owner does no locking,
thus you can be sure that nobody it using the object when former owner is somewhere
out of the object.

Regarding implementation, I wanted to look for some opinions before starting to
implement something as big as this patch. Probably someone can look and say, hey
it is stupit, you forgot that.... FILL_IN ... ;-)

I hope I explained it better this time, I know my English not the best. At least
worse than my Python :-)

thanks for your time, Martin


More information about the Python-Dev mailing list