Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail
From: ittium <ittium@gmail.com>
Newsgroups: comp.programming.threads
Subject: (context switch + condition variable+ mutex) Vs Few Mutex
Date: Thu, 11 Aug 2011 11:07:59 +0530
Organization: A noiseless patient Spider
Lines: 23
Message-ID: <j1vpro$bs8$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 11 Aug 2011 05:38:00 +0000 (UTC)
Injection-Info: mx04.eternal-september.org; posting-host="YDpysVqFc1vUUcjnd9eQOw"; logging-data="12168"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+unmTV8eipeZc6GMJ1bQR9"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
Cancel-Lock: sha1:J6KA4QptlErjYst8BfK2TJ16Ym0=
Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:503


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