I can not see the additional complexity, could you please give me a hint for some research on the matter?

If the issue is only related to how actually recover a consistent state in the data protected by the mutex, then I have ways to deal with that, for my specific application at least: I was thinking of storing a function object in my cache-mutex that would notify higher level code of the issue and start the recovery procedure for the data since I have redundancy. And, if worst comes to worst, I can also afford to "discard" the computations performed by the thread accessing the mutex until its content is marked as good by the higher level code.

Thanks

On Monday, July 6, 2015, Ion Gaztañaga [via Boost] <[hidden email]> wrote:

El 06/07/2015 a las 19:43, Malko escribió:

> If there is none, I would really need to modify your files for my project to
> work, and I would appreciate if you could confirm a couple of things for me.
> In http://stackoverflow.com/a/1179766/4598277 it is mentioned to modify two
> files:
> 1. posix/thread_helpers.hpp to set the attribute (first time ever I was
> happy to get an exception :D)
> 2. posix/mutex.hpp to handle the EOWNERDEAD return value
> Can you please confirm if this would be enough? It would seem so to me, but
> I have only studied parts of your code.
>
> Thank you for the assistance.
I think that would be a start point. If you need something like
pthread_mutex_consistent() then things start to complicate.

Ion
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users

If you reply to this email, your message will be added to the discussion below:
http://boost.2283326.n4.nabble.com/Interprocess-posix-robust-mutex-and-EOWNERDEAD-tp4677852p4677863.html

To unsubscribe from [Interprocess] posix robust mutex and EOWNERDEAD, click here.
NAML