boost.interprocess shared memory & stability when a linked application terminates abnormally
What would happen when a linked application to a shared memory terminates abnormally while it is in the middle of memory allocation or any other structural changes? I guess it could corrupt the whole shared memory and also stability of the other linked applications. Some shared-memory based databases like TimesTen have a mechanism called MicroLogging to protect integrity of the shared memory. Here is a quote from Oracle TimesTen: "Oracle TimesTen protects its shared libraries against application process failures by means of its patented “MicroLogging” algorithm. Consequently, the abnormal termination of a linked application will not affect Oracle TimesTen IMDB's and even other related applications."
Bijan wrote:
What would happen when a linked application to a shared memory terminates abnormally while it is in the middle of memory allocation or any other structural changes? I guess it could corrupt the whole shared memory and also stability of the other linked applications.
Yes. Basically the same that you have when a process writing to a file dies.
Some shared-memory based databases like TimesTen have a mechanism called MicroLogging to protect integrity of the shared memory. Here is a quote from Oracle TimesTen: "Oracle TimesTen protects its shared libraries against application process failures by means of its patented “MicroLogging” algorithm. Consequently, the abnormal termination of a linked application will not affect Oracle TimesTen IMDB's and even other related applications."
Interesting. I don't know how they do this, but surely this can be achieved with a layer above Interprocess. Sadly I have no time to implement something like this for the moment, but if someone can give me some ideas, I'll try to investigate it to see how complex the solution can be. Regards, Ion
Ion Gaztañaga
Bijan wrote:
What would happen when a linked application to a shared memory terminates abnormally while it is in the middle of memory allocation or any other structural changes? I guess it could corrupt the whole shared memory and also stability of the other linked applications.
Yes. Basically the same that you have when a process writing to a file dies.
Some shared-memory based databases like TimesTen have a mechanism called MicroLogging to protect integrity of the shared memory. Here is a quote from Oracle TimesTen: "Oracle TimesTen protects its shared libraries against application process failures by means of its patented “MicroLogging” algorithm. Consequently, the abnormal termination of a linked application will not affect Oracle TimesTen IMDB's and even other related applications."
Interesting. I don't know how they do this, but surely this can be achieved with a layer above Interprocess. Sadly I have no time to implement something like this for the moment, but if someone can give me some ideas, I'll try to investigate it to see how complex the solution can be.
Regards,
Ion _______________________________________________ Boost-users mailing list Boost-users <at> lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Ion, I guess at least the memory allocation layer which is the lowest layer should be transactional. Here are some info that I found: DracoSTM: A Practical C++ Approach to Software Transactional Memory http://lcsd.cs.tamu.edu/2007/final/5/5_Paper.pdf Transactional Memory by Jim Larus (Author), Ravi Rajwar (Author), Mark D. Hill http://www.amazon.ca/Transactional-Memory-Jim-Larus/dp/1598291246/ref=sr_11_1/702-7387355-6996836?ie=UTF8&qid=1214514245&sr=11-1 Regards, Bijan
Bijan wrote:
Ion,
I guess at least the memory allocation layer which is the lowest layer should be transactional. Here are some info that I found: DracoSTM: A Practical C++ Approach to Software Transactional Memory http://lcsd.cs.tamu.edu/2007/final/5/5_Paper.pdf
Transactional Memory by Jim Larus (Author), Ravi Rajwar (Author), Mark D. Hill http://www.amazon.ca/Transactional-Memory-Jim-Larus/dp/1598291246/ref=sr_11_1/702-7387355-6996836?ie=UTF8&qid=1214514245&sr=11-1
Regards, Bijan
Thanks for the info, Ion
participants (2)
-
Bijan -
Ion Gaztañaga