Thread Management Woes

I posted about this here...

The basic idea with the experimental six-thread testing method is to speed up the overall testing process. But how?

Well, I started on it last night when I randomly got the idea, and drew out a schematic whilst bored in class earlier today. I call it "Reverse," which is probably a bad name, but does describe what half of the threads do.

Threads 1, 2, and 3 each look for the first factor of the Proth number. Upon finding it, they test like this:

• first factor + 1 up to sqrt(Proth)/2 with first factor += 3
• first factor + 2 up to sqrt(Proth)/2 with first factor += 3
• first factor + 3 up to sqrt(Proth)/2 with first factor += 3

Threads 4, 5, and 6 don't care about the first factor, but they do care about the square root. They care a lot. They set the variable mpTrial to sqrt(Proth) and test like this:

• mpTrial -1 down to sqrt(Proth)/2 with mpTrial -= 3
• mpTrial -2 down to sqrt(Proth)/2 with mpTrial -= 3
• mpTrial -3 down to sqrt(Proth)/2 with mpTrial -= 3 

This effectively cuts the testing range (from 2 to the square root) in half.

However, it does not work properly. Not at all. In fact, it only does some of what it's meant to do. That's why I was posting about thread management (of the SAFE variety) and why GJSieve 2.0 is not available to download!

Naturally, now that I know how to multi-thread my application, I have found excuses to do it just about everywhere. Yet to come is a separate thread for calculating (as opposed to testing) the number, so that the application doesn't seize up when you tell it to calculate a million+ digit number. That ought not be too difficult.

More on GJSieve's crazy threading later.