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.
