|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 3 of 6
PrimeNumberSource findPrimeNumbers(BigInteger lowerBound,
BigInteger upperBound);
Observe that com.javaworld.primefinder.PrimeNumberSource is the interface to which the result handle must conform. It defines a single method, BigInteger nextPrime(), which, when invoked, should return the next element in the search results buffer. If the results buffer has been exhausted,
the implementation must return null to indicate that no further results are available. As already mentioned, the implementation of this method must be thread-safe.
Note that the emphasis of this task is on finding the probable primes within the search range; this makes it possible to use
the nextProbablePrime() method from the java.math.BigInteger class. You can wrap the call to this method in a static method of the utility class com.javaworld.primefinder.PrimeUtil, an excerpt of which is shown in Listing 2.
public static BigInteger findFirstPrime(long lowerBound, long upperBound)
{
BigInteger result;
BigInteger startPos = BigInteger.valueOf(lowerBound);
BigInteger nextProbablePrime;
if (startPos.isProbablePrime(.....)) // some reasonable accuracy
nextProbablePrime = startPos;
else nextProbablePrime = startPos.nextProbablePrime();
if (nextProbablePrime.longValue() >= upperBound)
result = null;
else result = nextProbablePrime;
return result;
}
Having defined the public interfaces and utilities on which the solution is to be built, you can now move onto the task of detailing it. You'll begin by defining the thread gate implementation, which provides the means of controlling access to the results buffer.
The objective of the thread gate is to ensure that multiple readers can access the prime numbers buffer without preventing the search threads from adding results to it.
A reader thread should be able to pick up any available results from the handle without waiting; but if there are no results, it must queue until at least one is made available. The sample application employs a fair scheme so that results are handed out more or less in the order in which the threads arrive. And yes, I mean it when I say "more or less." The emphasis is not on dispensing results in strict queuing order; rather, threads that request primes around a given interval will all receive their data roughly at the same time -- before the arrival of the next batch of threads.
A real-world analogy that illustrates this scheme is that of the modern coffee shop. The inoffensive way in which coffee orders are "batched" during busy periods is interesting. The attendants at the till take the customer orders and shout them down the line to the baristas manning the espresso machines, who in turn prepare several cups of coffee from the same espresso batch and dispense them to the waiting customers at roughly the same time. Then, of course, they return to the task of making the next batch of coffee for the next batch of customers, and the cycle repeats ad infinitum. By this strange internal scheme, people who arrive at the queue within a given interval tend to get their coffees around the same time -- although not exactly in the order in which the requests were made. Presumably the espresso machines can only prepare so many cups of coffee at any point in time, and it would simply be inefficient or slow to prepare the cups individually.
java.util.concurrent that can be used to speed up time-consuming tasks in multithreaded Java applications.