[Cython] Acquisition counted cdef classes

[mark florisson]

On 25 October 2011 05:47, Robert Bradshaw <robertwb at math.washington.edu> wrote:
> On Mon, Oct 24, 2011 at 2:52 PM, mark florisson
> <markflorisson88 at gmail.com> wrote:
>> On 24 October 2011 22:03, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>>> mark florisson wrote:
>>>>
>>>> These will by default not lock for operations to allow
>>>> e.g. one thread to iterate over the list and another thread to index
>>>> it without lock contention and other general overhead.
>>>
>>> I don't think that's safe. You can't say "I'm not modifying
>>> this, so I don't need to lock it" because there may be another
>>> thread that *is* in the midst of modifying it.
>>
>> I was really thinking of the case where you instantiate it in Cython
>> and then do some parallel work, in which case you're the only user.
>> But you can't assume that in general.
>
> It could be useful to assert for a chunk of code that a given object
> is read-only and will not be mutated for the duration of the context
> (programmer error and strange crash/data corruption if it is). E.g.
>
> with nogil, assert_frozen(my_dict):
>    a = (<CdefClass>my_dict[key]).c_attribute
>    [...]
>
> All references obtained could be borrowed. Perhaps we could even
> enforce this for cdef classes (but perhaps not consistently enough,
> and perhaps that would make things even more confusing). Just a
> thought.

Hmm, I actually think that passing around references in general
(without having to declare them as borrowed in parameters) would be a
good feature. If my_dict would be e.g. a cython.types.dict, then it
would only accept CythonObjects, so it could just do the acquisition
counting.

For cython.parallel we could provide types more suited for the
cython.parallel kind of fine-grained parallelism, e.g. lock for
writes, don't lock for reads, which allows either to happen
simultaneously, but not any mixing of those two. Through explicit or
implicit barriers one may be sure that operations are correct.

> - Robert
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>