On 25 October 2011 05:47, Robert Bradshaw <rober...@math.washington.edu> wrote: > On Mon, Oct 24, 2011 at 2:52 PM, mark florisson > <markflorisso...@gmail.com> wrote: >> On 24 October 2011 22:03, Greg Ewing <greg.ew...@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@python.org > http://mail.python.org/mailman/listinfo/cython-devel > _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
