Subj : Re: Avoiding synchronization (pthreads) To : comp.programming.threads From : David Schwartz Date : Wed Mar 02 2005 08:51 pm "Ian Pilcher" wrote in message news:_7OdnQu-xMkKDrvfRVn-ug@comcast.com... > Like the OP, however, I would like to avoid excessive calls to the > pthread APIs. In my case, the reason is error handling rather than > performance. Call me overly pedantic, but I believe that a well written > program should test the return value of every function call that can > fail and handle failures appropriately. > > This sounds good until you try to figure out how to "appropriately" > handle the fact that pthread_mutex_unlock can fail on alternate Tuesdays > (my interpretation of XSH 2.3). It effectively makes it impossible to > write error handling code that doesn't require it's own error handling > logic, ad infinitum. > > I'm interested in hearing how people handle this situation in a > professional environment, where the code has to get out the door -- > ignore the possibility that the call may fail, fill the code with aborts > (or something equally drastic), or something incredibly clever that I > haven't thought of. If pthread_mutex_unlock fails, there usually isn't much you can do but terminate the program. This would indicate either a severe bug in your program (such as unlocking a mutex after it had been destroyed or unlocking a mutex not held) or some extreme problem with the environment. This is not analogous to out of memory or out of resources type problems that you can and should try to handle smoothly. DS .