|
From: Russ F. <rus...@ho...> - 2004-04-26 14:04:54
|
>From: Alberto Alonso <al...@gg...> > >Where can I get more info on ERRORCHECK_MUTEX? > On Linux, the pthread_mutexattr_init(3) discusses PTHREAD_MUTEX_ERRORCHECK_NP, which is a set of parameters that you use in a call to pthread_mutexattr_settype when setting up your mutex attribute structure. It is a non-standard extension to the POSIX standard, it is only available on the Linux threads implementation, so it likely will not be portable; however, for debugging, it's good to use at least in the first several rounds of testing. What distinguishes error checking mutexes from others is that they track the current "possessor" (thread that is in control) of the mutex. If a mutex locker tries to lock the mutex again, which would result in a deadlock, the pthread_mutex_lock call returns EDEADLK. Additionally, if someone other than the current possessor of a mutex tries to unlock it, pthread_mutex_unlock returns EPERM and does not unlock the mutex. The default kind of mutex, presumably called "fast mutexes" in the Linux impl, will permit deadlock to occur and will permit non-possessors to unlock mutexes. _________________________________________________________________ Get rid of annoying pop-up ads with the new MSN Toolbar FREE! http://toolbar.msn.com/go/onm00200414ave/direct/01/ |
|
From: Alberto A. <al...@gg...> - 2004-04-26 21:01:53
|
This is really great stuff. Thanks for all the info. I need valgrind to figure out why my program breaks when the number of threads gets near 300. Now I am getting the info as to what I've been doing wrong all along within the core threads. Thanks again, Alberto On Mon, 2004-04-26 at 09:04, Russ Fink wrote: > >From: Alberto Alonso <al...@gg...> > > > >Where can I get more info on ERRORCHECK_MUTEX? > > > > On Linux, the pthread_mutexattr_init(3) discusses > PTHREAD_MUTEX_ERRORCHECK_NP, which is a set of parameters that you use in a > call to pthread_mutexattr_settype when setting up your mutex attribute > structure. It is a non-standard extension to the POSIX standard, it is only > available on the Linux threads implementation, so it likely will not be > portable; however, for debugging, it's good to use at least in the first > several rounds of testing. > > What distinguishes error checking mutexes from others is that they track the > current "possessor" (thread that is in control) of the mutex. If a mutex > locker tries to lock the mutex again, which would result in a deadlock, the > pthread_mutex_lock call returns EDEADLK. Additionally, if someone other > than the current possessor of a mutex tries to unlock it, > pthread_mutex_unlock returns EPERM and does not unlock the mutex. > > The default kind of mutex, presumably called "fast mutexes" in the Linux > impl, will permit deadlock to occur and will permit non-possessors to unlock > mutexes. > > _________________________________________________________________ > Get rid of annoying pop-up ads with the new MSN Toolbar FREE! > http://toolbar.msn.com/go/onm00200414ave/direct/01/ -- Alberto Alonso Global Gate Systems LLC. (512) 260-2523 http://www.ggsys.net Hardware, consulting, collocation, monitoring and remote backups |