Re: GH replacement proposal (includes a bit of Unicode)

[Marius Vollmer]

Andreas Rottmann <address@hidden> writes:

> Marius Vollmer <address@hidden> writes:
>
>>> I'm a little wary of the locking, especially global locking, but I
>>> suppose it may well be necessary.  I don't have a strong feeling
>>> either way offhand, but presuming for the moment that it is necessary,
>>> then is there any way to lock down a particular value rather than the
>>> entire heap?
>>
>> Having a lock for every object would have a high overhead and give you
>> very little in terms of performance, I guess.  Also, they would be
>> tricky to use.
>>
> Why would the overhead be significantly larger than for one object?
> Pika will have per-object locks, and I think the implementation chosen
> has little overhead over global locking.

Ahh, I don't know about that implementation.  How large is the
overhead? (in bits/object, say.  URL perfectly OK.)

>> When you need to lock two objects, there would be the danger of
>> deadlocks, when other code needs to lock the exact same two objects,
>> but does it in reverse order.
>>
> You could probably solve this by having an poeration that does an
> "atomic" lock of serveral objects. Naive algorithm:
>
> 1) lock all objects you can
> 2) if that's all:
>      fine
>    else:
>      release all objects locked previously, wait a bit and goto 1)

Yes, but I would count this as 'significant overhead' ;-)

>> You would also have to allow locking an object twice, further
>> increasing overhead.
>>
> Why do you need to lock an object twice?

You don't need to, but you can't avoid, in general (I think).  The
might be some code path that locks one object twice without anyone
intending this.

But, yeah, you can partition your code into two kinds, just like with
a single global lock: When you have locked some objects, you can't
call functions that lock more objects.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405