Threaded Work Files

Multithreaded Work

The Multithreaded Work classes make it easyer to do a list of IWork/Work in a loop.

 The idea was made when:
My friends asked me to create a script that visits an url every 12 hours, sends data and checks if it was a success. And all that for every account (and that another 5 times for every category). (Kind of cheating yes, but for me as a programmer it was just fun)

My job was simple, one thread in a loop that does it's job for every account. The problem was it was slow. There were around 100 account names in the file. So it took a while doing everything. If it takes an hour for all the votes (yes sometimes it was that long), then some accounts have to wait 13 hours. My program wasn't a success.

When I made it multithreading (around 30 threads I used) it only took 10 minutes. It was a great improvement. Since it's over internet 30 threads was fine even it was a dual core since not 100% of the cpu is taken.

I lost my overhead again so I rewrote the program in a night. I made a database that contains all the account names and made a method called 'getFirstAvailableAccount'. It returned null if there was no account available. The overhead was back again. After viewing my code 3 months later I really had to look what I did where. Overhead was gone, but after 10 minutes I knew again how my code was written. 10 minutes for my code I was proud of, isn't something to be proud of. So I decided to make a very standard and easy library of my url-visiting-by-account-program.


This is my current final library. Since I've written it in less than a day there sure are bugs.


 A little explanation of my library:

- IWork:
	A VERY simple interface.

- Work:
	An abstract class that implements IWork. This is a basic implementation of the IWork interface. It does what most 'IWork's would do: If this job is running, it's unavailable, else it's available. Simple 'IWork's will extend this abstract class.

- Employee:
	As a developer normally you don't need this. Actually you really dont!!! It implements Runnable so I can make a thread from that class. It asks his boss (Employer) for an IWork, and sleeps for 'timeout' if there is no IWork to do.

- Employer:
	I call this the 'boss' class. The 'Employee's ask 'getWork' from this class. It's that simple. The Employer starts the work already so in any case the work can be started twice (if the interface or abstract class is used well). You can stop the employees too with 'stopEmployees'. The Employees will stop if their current work is done. They don't stop in the middle of their job. To stop the threads too you use 'stopWork'. 'stopWork' also stops the employees. The difference is that while calling 'stopWork', the method stops until all current works are done. It's not a good idea to implement a while (true) loop in your work, unless you stop your work another way. Else you won't be able to close your program.

I had problems finding names for my classes and interfaces. I think this is the best and most understandable names I could give them. An Employer gives IWork/Work to Employees. The only 'strange' thing you can say is that here you do the same IWork/Work when it's ready in the list again.

The class TimeTeller in the package examples is the easyest class to explain how to use the interface in stead of the abstract class.