Re: squid-smp: synchronization issue & solutions

On 11/15/2009 11:59 AM, Sachin Malave wrote:

> Since last few days i am analyzing squid code for smp support, I found
> one big issue regarding debugs() function, It is very hard get rid of
> this issue as it is appearing at almost everywhere in the code. So for
> testing purpose i have disable the debug option in squid.conf as
> follows
>
> -------------------------------
> debug_options 0,0
> -------------------------------
>
> Well this was only way, as did not want to spend time on this issue.....

You can certainly disable any feature as an intermediate step as long as
the overall approach allows for the later efficient support of the
temporary disabled feature. Debugging is probably the worst feature to
disable though because without it we do not know much about Squid operation.

> Now concentrating on locking mechanism...

I would not recommend starting with such low-level decisions as locking
mechanisms. We need to decide what needs to be locked first. AFAIK,
there is currently no consensus whether we start with processes or
threads, for example. The locking mechanism would depend on that.

> As OpenMP library is widely supported by almost all platforms and
> compilers, I am inheriting locking mechanism from the same
> Just include omp.h & compile code with -fopenmp option if using gcc,
> Other may use similar thing on their platform, Well that is not a big
> issue..

After spending 2 minutes on openmp.org, I am not very excited about
using OpenMP. Please correct me if I am wrong, but OpenMP seems to be:

- An "approach" or "model" requiring compiler support and language
extensions. It is _not_ a library. You examples with #pragmas is a good
illustration.

- Designed for parallelizing computation-intensive programs such as
various math models running on massively parallel computers. AFAICT, the
OpenMP steering group is comprised of folks that deal with such models
in such environments. Our environment and performance goals are rather
different.

> 1. hash_link ---- LOCKED
>
> 2. dlink_list ---- LOCKED
>
> 3. ipcache, fqdncache ---- LOCKED,
>
> 4. FD / fde handling ---WELL, SEEMS NOT CREATING PROBLEM, If any then
> please discuss.
>
> 5. statistic counters --- NOT LOCKED ( I know this is very important,
> But these are scattered all around squid code, Write now they may be
> holding wrong values)
>
> 6. memory manager --- DID NOT FOLLOW
>
> 7. configuration objects --- DID NOT FOLLOW

I worry that the end result of this exercise would produce a slow and
buggy Squid for several reasons:

- Globally locking low-level but interdependent objects is likely to
create deadlocks when two or more locked objects need to lock other
locked objects in a circular fashion.

- Locking low-level objects without an overall performance-aware plan is
likely to result in performance-killing competition for critical locks.
I believe that with the right design, many locks can be avoided.

I think our first questions should instead include:

Q1. What are the major areas or units of asynchronous code execution?
Some of us may prefer large areas such as "http_port acceptor" or
"cache" or "server side". Others may root for AsyncJob as the largest
asynchronous unit of execution. These two approaches and their
implications differ a lot. There may be other designs worth considering.

Q2. Threads versus processes. Depending on Q1, we may have a choice. The
choice will affect the required locking mechanism and other key decisions.

Thank you,

Alex.
Received on Mon Nov 16 2009 - 16:12:46 MST