Greg Ewing wrote:
> Martin Devera wrote:
>
>> Greg, what change do you have in mind regarding that "3 instruction
>> addition" to refcounting ?
>
> I don't have any change in mind. If even an atomic inc
> is too expensive, it seems there's no ho
> Ah, I think I understand now. First the minor critique: I believe
> the locking algorithm isn't thread-safe:
>
> while (ob->owner_thread != self_thread()) {
>unlock_mutex(thread_mutex[self_thread()])
> // wait for owning thread to go to quiscent state
>lock_mutex(thread_m
Greg Ewing wrote:
> Martin Devera wrote:
>
>> As I've written in "Big reader lock" paragraph of the original
>> proposal, these
>> objects could be handled by not blocking in read path
>
> But as was just pointed out, because of refcounting,
> the
>> 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.
>
> Which thread owns builtins? Or module dictionaries? If two threads are
> running the same f
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
Hello,
as someone has written in FAQ, sometimes someone starts a thread about
finer grained locking in Python.
Ok here is one.
I don't want to start a flamewar. I only seek suggestions and constructive
critic. I have some ideas whose are new in this context (I believe) and
I only wanted to make t
