-2

In my application written in C language I have two threads:

The first thread contains a UDP listener used for Interprocess Communication for signalling purposes. When a signal arrives to this thread, it tries to lock the second thread using pthread_mutex_lock to execute some functions and after that it unlocks it, and the second thread continues it normal execution.

I noticed that locking the thread consumes too much time for example around 100 ms, which is too much. But sometimes it consumes not much around 10 ms which is OK for me.

So can anyone tell me what is happening, why I am getting that much of time variation in my executable code? Is there any better way to achieve what I am doing in a better way i.e. locking and unlocking?

Note: I am running my application in a Virtual Machine with Linux Ubuntu x64 bit, with 2GB ram and 2 CPUs, the final output is in release mode.

wojciii
  • 4,253
  • 1
  • 30
  • 39
IoT
  • 607
  • 1
  • 11
  • 23
  • 1
    can you show us some code(locking the other thread), how do you measure the time in your program ? – aze Jun 25 '14 at 13:36
  • Perhaps the other thread is busy, and holds the lock for 100ms. – nos Jun 25 '14 at 13:37
  • @nos I thought about that, since the second thread is always busy and goes into infinite while loop, so I put ulseep(5) inside the loop which would be enough for the UDP listener thread to lock the second thread. – IoT Jun 25 '14 at 13:41
  • I also think that you should post some of your code. So do you have one thread which produces something and another which consumes it and communicates this using UDP? – wojciii Jun 25 '14 at 14:13
  • @HA-AS That might not help if the issue is that the 2. thread _holds_ the lock for 100ms. However your issue could also be that your 2. thread does a lot of quick locking/unlocking of the mutex which might cause starvation, in which case you might need something like http://stackoverflow.com/questions/12685112/pthreads-thread-starvation-caused-by-quick-re-locking But it's almost impossible to give advice when we don't know how your code looks like and what the threads are actually doing _while_ they own the lock. – nos Jun 25 '14 at 14:21
  • @HA-AS you may try using some tools to detect thread contention and analyze your code – PankajM Jun 25 '14 at 16:56
  • Without seeing the code. We can only assume so much. Assuming that only one thread can lock the second thread, then your second thread's execution just takes too long. Take a look at the calls the second makes and measure the time from each function call. The second possible issue is that your monitoring tool is just slow. Slowing down the performance overall and causing a delay itself when you call to start the timer and when you stop. – Tim Z. Jun 25 '14 at 17:57

1 Answers1

1

Restating the problem: you have a worker thread in charge of processing some data, and a monitor thread which controls the worker's activity. You wish to know why there is a latency in stopping the worker thread through a mutex contention lock.

A mutex may block a thread only when this thread is trying to lock it. If that thread is going through some computation before reaching that point where it tries to lock the mutex, you will experience a latency. That latency will vary depending on where the thread execution is at when your monitoring thread locks the mutex.

The only way to reduce latency is to reduce the work load between mutex lock attempts, but this will also reduce throughput.

didierc
  • 14,572
  • 3
  • 32
  • 52