Re: worker threads - one does all the work

regardless of the number of worker threads I create, one of them does most - about 70% - of the work.

When the thread that processes the last trap finishes with it, it is still running (has a timeslice), so it immediately loops back and attempts to obtain the lock. Most of the time it will succeed because none of the other threads are running at that moment in time. The other threads will only get a look in if this thread is swapped out; and that will only happen if it takes longer than its timeslice to process the previous trap.

I'm not overly familiar with *nix system priorities and scheduling, but the idea of using a file system lock, even if it is cached, as a distribution mechanism for network IO traffic seems a little like putting a lollipop lady on a motorway. "Scalable" isn't the word that comes to mind here.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.

In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit

Comment on Re: worker threads - one does all the work


Come for the quick hacks, stay for the epiphanies.
	PerlMonks