Unlcoking a mutex from crashed thread

In my mulithreaded C application, one of task got crashed while holding a mutex lock. This is now causing problem for other threads to execute with access to same semphores.
I know in linux we have robust mutex to deal with it, but using this will require lots of changes in application(not possible). So can anybody tell me a way to unlock the mutex or solve the problem.
As a solution I am thinking of deleting the locked mutex and recreating it for rest of the thread to use. I am not sure how safe is to implement this change.

Thanks.

It is not clear wht do you mean here: task got crashed. If exception is unhandled, the whole program crashes. If exception is caught, here is the place to release the mutex.

This is the main reason to use RAII and why this makes C++ a better language than C to handle this sort of thing.

For C. You'll need to unlock he mutex "somehow". This will probably involve quite a bit of nasty code to do so (pretty much simulating what a MutexLock object would do).

Or the other solution. fix your code so it doesn't throw exceptions and allow the exceptions to remain unhandled.

Quote:

---

Originally Posted by Alex F

It is not clear wht do you mean here: task got crashed. If exception is unhandled, the whole program crashes. If exception is caught, here is the place to release the mutex.

---

Sorry for not putting it in a clear way. By task I meant 'a thread'. it is a multithread application in C. Rest of the thread are getting stuck cause of forever locked mutex.
I have no idea how to unlock a mutex which in lokced state due to a crashed thread.

Why is the thread crashing - and in particular why crashing when holding a mutex? How does another thread know that this thread has crashed - whether it's holding a mutex or not? When trying to obtain the mutex, don't you use a time-out interval so that threads waiting for the mutex are never stuck forever?

It is still not clear what do you mean by "crashed thread". Can you be more specific? Usually, when any thread in the process crashes, the whole process it terminated.

Quote:

---

Originally Posted by 2kaud

Why is the thread crashing - and in particular why crashing when holding a mutex? How does another thread know that this thread has crashed - whether it's holding a mutex or not? When trying to obtain the mutex, don't you use a time-out interval so that threads waiting for the mutex are never stuck forever?

---

Actually these are VxWorks tasks that run independent to each other.
We are not sure why task is crashing may be because of socket error, hardware failure or SSL issue. We are not able to find out the crash cause yet.

The mutex guards a socket send routine, if one thread does't release it other thread wont't be able to use the socket access routine.
we can not put a timeout in the mutex lock as it will skip the socket data send.

In short it doesn't matter much if one thread or task is crashed, we are more concerned about locked resources(mutex here). How can we get it back for other thread to work?

I am thinking of deleting and recreating the mutex(if owner task is in suspend state), would it be a good idea to do so ?

Quote:

---

Originally Posted by Alex F

Usually, when any thread in the process crashes, the whole process it terminated.

---

nope. not necessarily. if you want that behaviour like that, you need to code it that way.

how your C++ framework handles uncaught C++ exceptions or how it handles uncaught hardware exceptions is implementation dependant.

What are you using to obtain the lock on the mutex? Are you checking its return code (e.g. WAIT_ABANDONED?)

Quote:

---

Originally Posted by abhi009

We are not able to find out the crash cause yet.

---

so, I suppose that the thread is probably invoking undefined behavior somewhere ( otherwise, you should be able to easily find out where the error occurs ) ...

Quote:

---

Originally Posted by abhi009

In short it doesn't matter much if one thread or task is crashed, we are more concerned [...]

---

are you sure ? being undefined behavior anything could happen, eg the crashing thread could have corrupted memory accessed by other threads ( including the data of any mutex release mechanism you come out with ) rendering your efforts moot. You have a bug, you should fix it.

FYI, as other said, many aspects of exception handling ( especially on UB conditions ) are hardware and implementation dependent, so, what OS should this run on ? ( if on Windows, note that there's a dedicated subforum for that ... )