| Marcel Müller 2008-01-22, 7:27 pm |
| Raxit@MyKavita.com wrote:
> normally the execution flow of many threaded programs are like
>
> pthread_mutex_lock
> do some critical region stuff.
> pthread_mutex_unlock
>
> with many if-else-<or switch case or other stuff.+ Loop etc>
>
> No Doubt, Clear Code is Good, but what harm if library<or
> implementation> itself keep Tracks of Lock Acquired by Particular
> thread and when Threads cancel/exit, it will release/unlock all the
> locks acquired by that thread.
As others stated before, that is not sufficient.
I usually use the object lifetime and stack unwinding features of OO
languages like C++ to keep track of mutexes or other external or
unmanaged resources - even in code that is mainly not OO. This is pretty
reliable unless your program dies in a very bad way, in which case it is
up to the operating system to clean up the sherds anyway.
Of course, you must not use non-returning C library functions like
pthread_exit in this case. But throwing some kind of
thread_abort_exception will do the job pretty well too.
> <so even dummy programmers write buggy
> program, it will not buggy :) >
That probably won't happen.
Furthermore there are other synchronization pitfalls like deadlocks
where no general solution is applicable. The are algorithms to detect
deadlocks, but they won't work if the deadlock is "distributed" over
multiple applications and/or servers.
Marcel
|