Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vdr] Re: Is cMutex class thread safe? Possible bug?



On Thursday 30 October 2003 6:39 pm, Klaus Schmidinger wrote:

[...]

> I have uploaded the current version of thread.[hc] to
> ftp://ftp.cadsoft.de/vdr/Developer. This is a version which has
> been modified to run on NPTL systems and uses PTHREAD_MUTEX_ERRORCHECK_NP
> as suggested by Stefan Huelswitt.

The new Mutex itself is not recursive. There are certain instance where there 
will be attempts to lock the Mutex multiple times recursivly. The ERRORCHECK 
attribute will prevent bad things from happening. But attempting to lock a 
non-recursive Mutex is still an ERROR.

What about this variant (untested):

class cMutex {
public:
   typedef enum { Normal, Recursive } Attribute;

   cMutex( Attribute attr = Normal );
   .
   .
   .
}

cMutex::cMutex(Attribute attr)
{
  locked = 0;
  pthread_mutexattr_t m_attr;
  pthread_mutexattr_init( &m_attr );
  if (attr == Recursive)
       pthread_mutexattr_settype( &m_attr, PTHREAD_MUTEX_RECURSIVE );
  else
       pthread_mutexattr_settype( &m_attr, PTHREAD_MUTEX_ERRORCHECK_NP );
  pthread_mutex_init( &mutex, &m_attr );
  pthread_mutexattr_destroy( &m_attr );
}

void cMutex::Lock(void)
{
  if ((int ret = pthread_mutex_lock(&mutex)) != 0)
       esyslog("ERROR: pthread_mutex_lock failed with %d", ret);
  locked++;
}

This will retain the old ways, but will help highlight the places where the 
mutex should be recursive.

> I would assume that this version of thread.[hc] should also work with
> VDR 1.2.x, but haven't tested that. I didn't want to make this change
>
> before version 1.3, but for those who want to test it in 1.2, there it
> is.
>
> Klaus


Andreas



-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.



Home | Main Index | Thread Index