Hi,
there's an IMHO compelling reason why with-pointer-to-vector-data CANNOT be implemented using copying. As a result, the shareable vector API must be provided as a strictly optional, API on implementations that support it. The API's service would then merely be unification of various vendor APIs, a valuable goal for CFFI.
The reason is as follows: Sharing produces problems similar to those of multiprocessor machines with separate caches. AFAIK, the 68060 processor can sniff the bus while "idle" and invalidate (or possibly reload) its cache. CFFI cannot do this.
Trying to copy in one or the other direction does not implement sharing. It instead implements "with exclusive access from Lisp (resp. foreign) side within the scope of the body" -- depending on the direction of the copying.
Here's a testcase. Try to imagine the following within the body of a macro that surrounds it with copying the block in one direction or the other.
(setq/defparameter shared-array (make-shareable-byte-vector 2000)) (fill shared-array 2)
(with-pointer-to-vector-data (ptr shared-array) (loop for i below (length shared-array) when (oddp i) do (setf (aref shared-array i) (mod i 256)) else do (setf (mem-aref ptr :ubyte i) 17))) ;2nd loop to verify result on shared-array not shown, but trivial.
So what's the feature's name? #+cffi-feature:shareable-vector #+cffi-feature:shared-vector
Regards, Jorg Hohle.
Joerg-Cyril,
I'm not sure I fully understand your example or concern. I agree that sharing and copying do not have exactly the same semantics. For a wide array of applications, the outcome of "copy the CL array to a foreign array, pass the foreign array to a function, and copy it back to the CL array" and "pass this pointer to my CL array directly to C and let it operate" will be the same.
Obviously, if my program is multithreaded or the C program needs to maintain the state across calls or I don't know what else, then the semantics become very different.
It seems to me that a universal implementable "shared-vector" API will handle those cases where copying semantics are sufficient for correctness, and we want to share primarily for efficiency reasons. Since this seems to cover a lot of cases, why not provide this, with documentation caveats that it's not going to DTRT across all platforms if you require true sharing?
rif
Hi,
there's an IMHO compelling reason why with-pointer-to-vector-data CANNOT be implemented using copying. As a result, the shareable vector API must be provided as a strictly optional, API on implementations that support it. The API's service would then merely be unification of various vendor APIs, a valuable goal for CFFI.
The reason is as follows: Sharing produces problems similar to those of multiprocessor machines with separate caches. AFAIK, the 68060 processor can sniff the bus while "idle" and invalidate (or possibly reload) its cache. CFFI cannot do this.
Trying to copy in one or the other direction does not implement sharing. It instead implements "with exclusive access from Lisp (resp. foreign) side within the scope of the body" -- depending on the direction of the copying.
Here's a testcase. Try to imagine the following within the body of a macro that surrounds it with copying the block in one direction or the other.
(setq/defparameter shared-array (make-shareable-byte-vector 2000)) (fill shared-array 2)
(with-pointer-to-vector-data (ptr shared-array) (loop for i below (length shared-array) when (oddp i) do (setf (aref shared-array i) (mod i 256)) else do (setf (mem-aref ptr :ubyte i) 17))) ;2nd loop to verify result on shared-array not shown, but trivial.
So what's the feature's name? #+cffi-feature:shareable-vector #+cffi-feature:shared-vector
Regards, Jorg Hohle.
cffi-devel mailing list cffi-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
-
Hoehle, Joerg-Cyril -
rif