Perhaps it can be useful.
In my project ( Countertree ) I designed a new kind of mutex using only
atomic variables and the yield function. The performance is similar to the
native mutex of the compilers, and provide me flexibility for to design in
a easy way a mutex single writer multiple reader.
If you want to take a look you can see a description in
https://dl.dropboxusercontent.com/u/8437476/works/countertree_2.0/doc/single...
and the code is in the download option of the documentation project
https://dl.dropboxusercontent.com/u/8437476/works/countertree_2.0/doc/index....
If you need any explanation, please, ask me , and I will try to explain.
regards
*The project countertree is the implementation of red-balck trees with
access by position and parallel algorithms.
It is pending of the final review since two years ago. I need reviewers for
the project.
It can be useful to the C++ community because don't exist at today (or at
least I don't know) any other library with these capabilities.
2014-07-18 9:08 GMT+02:00 Ladislav Sopko
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- boostiterprocessmutex-an-another-try
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
Hi,
Allocation of that 4MB is small fee for much better performance, because continuous search of files on disk slow it down really hard. Then I think to extend it with time stamp as
Niall Douglas wrote. I just need atomic CAS for 64bit. Cause the time stamp and process ID must be changed in one shot. Then I can skip many robust checks, if the time from last lock is shorter than some predefined interval. So many regular locks will neither test file lock and it will run faster. In case one process die, there will be expired timeout and lock candidate will go check file lock. I'll check if I can add a 64bit CAS in boost\interprocess\detail\atomic.hpp. (if you know how it should be done, it will be a big help for me, cause I have not a lot of practice in atomic portable world.)
regards
-- 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. --
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost