Mutex Lock等待时间和看门狗

Question

We are measuring a performance scale of multi threaded real time application. I need to write a adapter to measure the time spent on

1. Waiting time for locking the mutex
2. Time spent between mutex.lock -> mutex.unlock : critical section execution time

and also component like locktimer or watchdog timer. If a thread holding a mutex lock for more than a configured time.. Have to notify to error log..

Any best way of doing this..?

Answer 1

You can take time(using standard ctime) before calling your mutex and after you get the mutex. Difference between those two will give you approximate time your thread waited to get mutex.
Similar process can be done for process 2 to find critical section execution time.

Answer 2

Maybe the RAII idiom helps you. For example:

class MutexHolder
{
public:
    MutexHolder()
    {
        //here you should take start time
        m_mutex.lock();
        //here you should take time and find a differnce between start time 
    }
    ~MutexHolder()
    {
        m_mutex.unlock();
        //here you should track the time spent between mutex.lock -> mutex.unlock and do smth else
    }
private:
    Mutex m_mutex;
};

Then use the class:

//your code

{//start of critical section
    MutexHolder lock;

    //code guarded by mutex locking

}//here the destructor of the MutexHolder object will call automatically

Answer 3

Something easy you can do is using sort of statistical counters. First define how many counters you need... say 10

int timecounters[10];

then use any timer you have... finer granularity and lower overhead are of course best... for example clock()/GetTickCount()/QueryPerformanceCounter/rdtsc. Finally use a stopwatch class like the following one

struct StopWatch
{
    int n;
    StopWatch(int n) : n(n) { timecounters[n] -= timer(); }
    ~StopWatch() { timecounters[n] += timer(); }
};

then for every section of code you need to trace write

{
    StopWatch sw(1);
    // code to be instrumented
}

At the end of execution of the program you'll have the total time spent in the various instrumented sections and the overhead should be quite low. It's also easy to add a limit check on single execution time... for example:

struct WatchDog
{
    int n, limit, start;

    WatchDog(int n, int limit) : n(n), limit(limit)
    {
        start = timer();
    }

    ~WatchDog()
    {
        int delta = timer() - start;
        if (delta > limit)
        {
            log("WatchDog(%i): Time limit exceeded (%i > %i)",
                n, delta, limit);
        }
        timecounters[n] += delta;
    }
};

Of course the WatchDog class will never interrupt an activity if it takes longer than it should... it will just report the problem at the end of the activity. A true interrupting general watchdog class is much more complex to implement.