Hello, I did try to continue with */Ion Gaztanaga's /*idea of portable robust mutex. I post my code and considerations in codereview. http://codereview.stackexchange.com/questions/57083/portable-c-boostiterproc... I hope to find some one to discuss about. thx -- Sopko Ladislav 3D Informatica, Via Speranza 35, 40068, S.Lazzaro di Savena - Bologna, Italy Tel: +39051450844 | Fax: +39051451942 WWW: http://www.3di.it Documentation: https://intra.3di.it/manuali/ - http://wiki.3di.it FTP: ftp://ftp@ftp.3di.it, Download:/3di, Upload:/incoming **** Informativa Privacy - Ai sensi del D. Lgs n. 196/2003 (Codice Privacy) si precisa che le informazioni contenuti in questo messaggio sono riservate e ad uno esclusivo del destinatario. Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie. Privacy Information - This message, for the D. Lgs m. 196/2003 (Privacy Code), may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addessee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thanks you for your cooperation. --
On 15 Jul 2014 at 17:42, Ladislav Sopko wrote:
I did try to continue with */Ion Gaztanaga's /*idea of portable robust mutex. I post my code and considerations in codereview.
http://codereview.stackexchange.com/questions/57083/portable-c-boostiterproc...
I've implemented this a few times, and I always did it by having the locker write the current time and the pid at the point of lock. If too much time elapses and it doesn't unlock, you can check the pid or simply force an unlock. It's certainly much lighter weight than use file locks. Those are slow and not portable. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
El 15/07/2014 17:42, Ladislav Sopko escribió:
Hello,
I did try to continue with */Ion Gaztanaga's /*idea of portable robust mutex. I post my code and considerations in codereview.
http://codereview.stackexchange.com/questions/57083/portable-c-boostiterproc...
I hope to find some one to discuss about.
thx
Hi, The portable mutex has been in dormant state for a long time, so thanks for recovering it ;-) It wasn't further developed and I think your proposal could be an improvement, although I still don't like the preallocation of a 4MB file. I have no much time lately to review and add improvements to Interprocess, but please add this link or the patch to a boost trac ticket or as a GitHub pull request so that this is not forgotten when I find some time. Best, Ion
On 15 July 2014 16:42, Ladislav Sopko wrote:
Hello,
I did try to continue with */Ion Gaztanaga's /*idea of portable robust mutex. I post my code and considerations in codereview.
http://codereview.stackexchange.com/questions/57083/portable-c-boostiterproc...
I hope to find some one to discuss about.
I'll have to take a good look at that code. In my attempt to implement a robust mutex that models the C++11 Mutex concept I decided to add a new overload of try_lock, taking a tag type to indicate you are prepared to deal with the inconsistent state. The C++11 try_lock() function only returns true or false, which can't support the third state that can occur when locking a robust mutex, and I didn't want to rely on users calling an extra function to query whether a successful try_lock was *really* successful (in generic code working with any Mutex type failing to handle the inconsistent state could be disastrous). If you call the normal zero-argument try_lock() on my type and it's inconsistent you get an exception and it's marked as unrecoverable. If you call the try_lock(robust_t) overload you get a chance to recover it. https://gitorious.org/redistd/redistd/source/0d9c849726729e66e5703fadba0222d...
On 24 Jul 2014 at 23:48, Jonathan Wakely wrote:
In my attempt to implement a robust mutex that models the C++11 Mutex concept I decided to add a new overload of try_lock, taking a tag type to indicate you are prepared to deal with the inconsistent state. The C++11 try_lock() function only returns true or false, which can't support the third state that can occur when locking a robust mutex, and I didn't want to rely on users calling an extra function to query whether a successful try_lock was *really* successful (in generic code working with any Mutex type failing to handle the inconsistent state could be disastrous).
If you call the normal zero-argument try_lock() on my type and it's inconsistent you get an exception and it's marked as unrecoverable. If you call the try_lock(robust_t) overload you get a chance to recover it.
I dislike this design approach. This is one of those few areas where I think an "inconsistent handling" callback handler is the best approach, with a default implementation using a heartbeat and pid based approach. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
participants (4)
-
Ion Gaztañaga -
Jonathan Wakely -
Ladislav Sopko -
Niall Douglas