Re: squid-smp: synchronization issue & solutions

[NP: eliding recipients I know are getting these mails through squid-dev
anyway]

On Mon, 16 Nov 2009 12:52:15 +1100, Robert Collins
<robertc_at_robertcollins.net> wrote:
> On Mon, 2009-11-16 at 00:29 +0530, Sachin Malave wrote:
>> Hello,
>>
>> 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.....
>
> Its very important that debugs works.

What exactly were the problems identified?

>
>
>> 1. hash_link ---- LOCKED
>
> Bad idea, not all hashes will be cross-thread, so making the primitive
> lock incurs massive overhead for all threads.
>
>> 2. dlink_list ---- LOCKED
>
> Ditto.
>

Aye. These two need to be checked for thread-safe implementations and any
locking done in the caller code per the distinctly named hash/dlink.

>> 3. ipcache, fqdncache ---- LOCKED,
>
> Probably important.
>
>> 4. FD / fde handling ---WELL, SEEMS NOT CREATING PROBLEM, If any then
>> please discuss.
>
> !!!! we need analysis and proof, not 'seems to work'.

Aye. NP: this is one of the critical data stores in Squid. I wouldn't be
too far off generalizing the "everything" up and down the request handling
uses it semi-'random access' directly or indirectly.

>
>> 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)
>
> Will need to be fixed.
>
>> 6. memory manager --- DID NOT FOLLOW
>
> Will need attention, e.g. per thread allocators.
>
>> 7. configuration objects --- DID NOT FOLLOW
>
> ACL's are not threadsafe.
>
>> AND FINALLY, Two sections in EventLoop.cc are separated and executed
>> in two threads simultaneously
>> as follows (#pragma lines added in existing code, no other changes)
>
> I'm not at all sure that splitting the event loop like that is sensible.
>
> Better to have the dispatcher dispatch to threads.
>
> -Rob

Amos
Received on Mon Nov 16 2009 - 02:45:25 MST