Home > Archive > Unix Programming > January 2008 > Why not to auto Unlock the Mutex when Thread cancelled/die/exit ?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Why not to auto Unlock the Mutex when Thread cancelled/die/exit ?
|
|
| Raxit@MyKavita.com 2008-01-22, 8:22 am |
| Hi,
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. <so even dummy programmers write buggy
program, it will not buggy :) > <its like very much conceptually
similar to Garbage Collection of Heap Memory.>
-Raxit
| |
| Raxit@MyKavita.com 2008-01-22, 8:22 am |
| On Jan 22, 5:01=A0pm, Joe Seigh <jseigh...@xemaps.com> wrote:
> Ra...@MyKavita.com wrote:
>
>
>
>
>
> Or a collection of garbage which is what you'll end up with if
> a program exits with the shared data in an inconsistent state.
no the problem is common use case of " Lock when you access critical
region and Unlock when you no longer want" but as folks are making
Mistakes, of Not-Unlocking <or not unlocking in All code Coverage
Area, even programmers, dont want to hold lock any more.> <Its like
you malloc, but you forgot to free, as i already mentioned.>
>
> Or you can look at it this way. =A0If inconsistency is not a problem,
Consistency is need to maintained with Lazy Programmers <like me :)
>in mind
> why use locks? =A0They just slow things down.
>
> --
> Joe Seigh
>
> When you get lemons, you make lemonade.
> When you get hardware, you make software.- Hide quoted text -
>
> - Show quoted text -
-Raxit
http://mykavita.com
| |
| Rainer Weikusat 2008-01-22, 8:22 am |
| "Raxit@MyKavita.com" <raxitsheth2000@gmail.com> writes:
> 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,
s/C.*,/working code would be nice to have,/
> 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.
The 'classical' answer to this question would be : "Computers are good
at following instructions, not at reading your mind". Eg, a way to
stop a set of threads is to have them all block on a locked mutex
which will never be unlocked. How is the library/ implementation
supposed to know that a particular mutex shouldn't really be locked at
some point in time, despite that it is locked?
| |
|
| On Jan 22, 6:40 am, "Ra...@MyKavita.com" <raxitsheth2...@gmail.com>
wrote:
> Hi,
>
> 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
pthread_exit() is called by the thread to terminate, I am sure you are
a nice person and when you do explicitly leave a thread you have
unlocked all your mutexes :-)
So that leaves you with the thread being canceled.
Canceling a thread is like optimizations:
rule 1, do not do it
rule 2 (for experts only), do not do it yet
More seriously, cancellation should be a last resort mechanism: when
you cancel a thread, do not forget that all the stuff you've been
using like mutexes, condition variables etc. that you did initialize
with pthread_*_init(...) do not get their corresponding
pthread_mutex_destroy(...) function called and hence you are leaking
resources - your pthread library resources (and potentially memory).
Plus canceling a thread held in a pthread_mutex_lock is not possible:
hope you know what you are dealing with when messing with
cancelation ;-)
> locks acquired by that thread. <so even dummy programmers write buggy
> program, it will not buggy :) > <its like very much conceptually
> similar to Garbage Collection of Heap Memory.>
Threads are like the rest of resources (memory, fd ...), only harder
to manage. Garbage collection is a trade off - a common trade off on
recent languages. I don't want to go off topic but you'll find people
who love it and people who hates it, both having very good arguments
for/against it.
My point is at that, for now, no such exist for thread and hence
you'll have to be nice to them ;-)
|
|
|
|
|