Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #503 > unrolled thread

(context switch + condition variable+ mutex) Vs Few Mutex

Back to article view | Back to comp.programming.threads

Contents

  (context switch + condition variable+ mutex) Vs Few Mutex ittium <ittium@gmail.com> - 2011-08-11 11:07 +0530
    Re: (context switch + condition variable+ mutex) Vs Few Mutex naveen <naveenkumarkaushik@gmail.com> - 2011-08-12 02:48 -0700
    Re: (context switch + condition variable+ mutex) Vs Few Mutex David Schwartz <davids@webmaster.com> - 2011-08-20 03:56 -0700

#503 — (context switch + condition variable+ mutex) Vs Few Mutex

Group,
I am designing a call processing module that reads the data from some fd 
and process it. I am analyzing two designs
1. One thread reads the data, apply a hash function on call identifier 
and find out worker thread id. Pass it to worker thread through a queue 
synchronized using condition variable. This ensures, All messages of a 
call are processed by same thread.  These threads will have their 
dedicated data sets. so no locks will be needed during processing.

2. In the second design, threads reads from the fd, get the call context 
and other data from mutex protected global data strucutres (map with 
around 1 million entries), and process the data.

In #1 there is contex switch and communication overhead since data will 
go through condition variable/mutex protected queue

In #2, each thread will have to lock/unlock 4-5 data structures (map) 
but there is no context switch.

Which scheme is better in terms of performance.
thanks
Ittium

[toc] | [next] | [standalone]

#511

On Aug 11, 10:37 am, ittium <itt...@gmail.com> wrote:
> Group,
> I am designing a call processing module that reads the data from some fd
> and process it. I am analyzing two designs
> 1. One thread reads the data, apply a hash function on call identifier
> and find out worker thread id. Pass it to worker thread through a queue
> synchronized using condition variable. This ensures, All messages of a
> call are processed by same thread.  These threads will have their
> dedicated data sets. so no locks will be needed during processing.
>

Thread that finds out the the target thread may become bottleneck at
the high load.

> 2. In the second design, threads reads from the fd, get the call context
> and other data from mutex protected global data strucutres (map with
> around 1 million entries), and process the data.
>

One million entries are OK for maps which on some platforms are
implemented using red-black tree.

> In #1 there is contex switch and communication overhead since data will
> go through condition variable/mutex protected queue
>

Do not forget caching issue when your message move from one core to
other since threads might be running on different cores.

> In #2, each thread will have to lock/unlock 4-5 data structures (map)
> but there is no context switch.

If contention is small, it will consume very few cpu cycle.

>
> Which scheme is better in terms of performance.

If you can make a prototype and do performance analysis, it will be
great. Share your results with the group. It may be helpful to few
more people in this group.

Naveen

[toc] | [prev] | [next] | [standalone]

#518

On Aug 10, 10:37 pm, ittium <itt...@gmail.com> wrote:

> In #1 there is contex switch and communication overhead since data will
> go through condition variable/mutex protected queue

> In #2, each thread will have to lock/unlock 4-5 data structures (map)
> but there is no context switch.

> Which scheme is better in terms of performance.

Almost certainly 2.

DS

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming.threads

csiph-web