3

We are building an extremely latency sensitive application. Our full application takes about 2500 clock cycles in a process apart from locking, and there are two locks that need to be acquired and released. We expect no contention 99.98% of the time. Using pthread lock and unlock takes about 1800 additional cycles. Any pointers in faster formulations ? Writing locks based on atomic operations might be tricky. We would prefer using standard code as in Linux headers or boost headers if possible.

Humble Debugger
  • 4,439
  • 11
  • 39
  • 56
  • If this is almost no-contention situation than you should try spin-lock first, they are better than lock ( in certain situation since it will prevent threads from going into block state ). atomic operations are also good choice, but to use them is difficult. Mainly atomic operation are used in scalability concerned programs. – peeyush Jul 19 '11 at 19:40
  • btw how have you profiled your code in such way ? – peeyush Jul 19 '11 at 19:45
  • Tried pthread_spinlock. ABout 40% less time in out context, but still way too much. I can try looking into atomic ops in http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Atomic-Builtins.html#Atomic-Builtins but this stuff can be tricky. – Humble Debugger Jul 20 '11 at 19:05

2 Answers2

2

As a suggestion, try spin_mutex from Intel's Threading Building Blocks library. It's open-source (GPLv2), so you can also inspect sources for implementation details.

Also you may look at this: Is my spin lock implementation correct and optimal?

Community
  • 1
  • 1
Alexey Kukanov
  • 12,479
  • 2
  • 36
  • 55
1

You don't have too many options. Pthread library is as general as possible. If you make it more specific, fewer people will use it, thus everybody ends up implementing their own, making a mess.

I'm afraid you will have to write your own, which specifically suit your requirements. I would suggest this as reading: http://kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html

I'm reading it myself.

tothphu
  • 899
  • 12
  • 21