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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
