Hi,
Is bknr-datastore thread save?
If we call the function make-blob-from-file it would create a blob object and will start copying the file. It seems to me that if we access the object before copying is completed its state would be undefined. Is there a known workaround? It should be some mechanism for locking/unlocking of blob objects.
Thanks.
Hi Kamen,
there is no provision for thread-safety in the bknr datastore. I don't have any need for thread safety, but if there are small patches which would help in such an environment, I'll be fine with having them. In general, I don't think that threads are such a good idea anyway.
Cheers, Hans
On Thu, Jan 26 2006, Hans Hübner wrote:
Hi Kamen,
there is no provision for thread-safety in the bknr datastore. I don't have any need for thread safety, but if there are small patches which would help in such an environment, I'll be fine with having them. In general, I don't think that threads are such a good idea anyway.
Dear Hans,
Thank you for your message. It is not that I have decided to use threads in my application. The thing is that I am not aware of the alternatives that the platform presents. I am coming from a Algol-derived languages land.
The application I am working on is a multiuser enterprise application. It definitely needs to be responsive. How would you achieve that without using threads with CL?
Thank you.
Regards,
Hi Kamen,
I have cross-checked the problem you pointed at, and in fact it is true: The file copying operation of the blob creation routines is not guarded against other processes accessing the datastore. I have not delved into this very far, but I suspect that under CMUCL and SERVE-EVENT based multiprocessing, no scheduling will occur during the file I/O operation, as the scheduler will run only when a file descriptor under control of the SERVE-EVENT subsystem is accessed. This is a guess only, though, and I have not looked up the source to verify what's going on. With a threaded Lisp, the mechanism could be much more problematic as the scheduler may run at any time and pre-empt the Lisp process, possibly in the middle of the file-copying operation.
It depends on your application if this is a problem. If your application does not use the blob until it has been put into some application-defined data structure (as opposed to using the class' index), the incomplete blob will be no problem - Only the external data will not be complete.
As we started implementing the datastore, we decided that the blob I/O operations should not be protected by the datastore locks, as this would possibly stall the system for a long time. This may or may not be good for your application, but it would require further analysis to really make a good judgement if blob writing should be further protected. This could, for example, be done with a "complete" slot that would be set after the blob has been completely written, in a seperate store transaction.
Note that cmucl provides cooperative multiprocessing which is preferable to preemptive threading in many respects. It is simpler to understand, implement and debug. The only real disadvantage it has (in my eyes, anyway), is the fact that no two processes can run at the same time, if two CPUs are available.
Cheers, Hans
-
Hans Hübner -
Kamen TOMOV