These three weeks we have suffered from projects on Multiple Thread. Here is my summary of these three projects.
【1】ALS Elevator (version 2)
(1) Design Strategy & Analysis
About Request Queue:
There may be thread security problems between add and fetch requests. After separating instructions to extract information and form into requests, they should all be put in a queue for later scheduling. When a request is added and another request is fetched in the same time in the same queue, security problem might happen. As a habit, I would choose LinkedBlockingQueue or synchronized funtions to help me solve this kind of problem. When choosing BlockingQueue, the inner of Java will help the user to maintain security of it. I can simply use "poll" or "offer" keywords to realize operations in a safe way.
About Schduler:
The Scheduler Class integrates information in Elevator, Floor, and Request and offers decisions based on the amount of movement and "carriable" problems. This is the intersection of all other informationwhen the elevators are running in their own algorithms, floors are showing whether they are buttoned or not, and requests are calling for attentions. To simplify the Scheduler Class and cause less security problems, it's very important to assign independent missions to the other Classes. To avoid mistakes due to the schduling of JVM, each function in the other Class should be synchronized.
(2) Measurement
* Avoid Code Reuse -> Use smarter tools or structure to manage data; Origanize similar code in the same function or interface.
* Explicit Expression -> Use explicit defination to add readability to the code.
(3) About Bugs
About Time:
Part of the output is simulated time. Since I didn't use the precise method of calculating time, there may be some bugs on time when input too many instructions in the same time, especially when they are not in the same line. If instructions are in the same line and separated by semicolon, InputHandler will read in the same time and assign same start time to them. However, if they are in different lines but input in the same time, due to the scheduling of JVM and my own structure, some of the instructions may not be read together with the others and their start time may be later then the actual input time.
About Carry:
The larger the amount of instructions, the more possible the problem will be exposed. When some instructions should be carried by others on the theory basis, they may not be read by InputHandler when the elevator has already reached their floor. In the case, they won't be carried by other instructions. This is mostly due to my structure and the JVM. Maybe this is a problem on the theory basis, however, in my opinion, it's acceptable in the real life. Because there won't be too many input at the same time and it's OK for people to wait for a few more seconds.
【2】IFTTT
(1) Design Strategy & Analysis
About Savefile:
Savefile Class is the key class in the program. Since the File Class offered in Java is not thread safe, we need to use Savefile to form a thread secure class employing functions in File. In this case, Savefile looks like a File wearing "synchronized" in each function.
About Monitor:
Montior Class is the core class, like Scheduler in the Elevator, managing changes in files. To better find changes in a simple and logical way, I used four LinkedBlockingQueue, which are deleteFiles, newFiles, modifiedFiles, and sizeChangedFiles. Monitor is a thread, which will run over and over agian. If the file is found in the deleteFiles queue and another file with same attribute except name is found in the newFiles queue, it means the file is renamed. Likeswise, if the file is found in the deleteFiles queue and another file with same attribute except the path of parent is found in the newFiles queue, it means the file is path-changed. Modified files and size-changed files would be found directly in the modifiedFiles and sizeChangedFiles queue.
(2) Measurement
* SRP: Some Classes like Savefile and Monitor may include too many functions. They should be organized better in a balanced way.
(3) About Bugs
About Folder:
There may be problems in recursion functions. When the instruction operates on folders, the result may be unpredictable.
About Recover:
After inputting recover instructions, the real file will be recover, however, the output name of the file might be wrong.
【3】Taxi (Version 1)
(1) Design Strategy & Analysis
About Thread Safety:
Thread Safety is still very important in this project. Since each taxi would be an independent thread, there would be over a hundred threads at the same time. In the Scheduler Class, it should add all selectable taxi in a queue before the first 3000ms and figure out the best taxi based on their optimal path. When the requests amount is small, there might be less conflictions. But as requests increase, the same taxi would be added into different request queue or cause many other thread safety problems. In this case, I use synchronized to protect functions and LinkedBlockingQueue to control the safety of data.
About Snapshot:
When decide which taxi should be in service, I choose to take snapshot of each selectable taxi to record their attribute at that moment.
(2) Measurement
* Avoid Code Reuse -> Use smarter tools or structure to manage data; Origanize similar code in the same function or interface.
(3) About Bugs
About Simulating Time:
Since my output time is calculated by "fake" time, there's a time difference between reading and fetching request. The standard time should be 3000ms and my output time might be 100ms more.
About Direction of Taxi:
This is not a bug, but I chose a more complicated way to decided the moving direction of taxis. If possible, I can chang it into a better way, using an array to record edges.
【4】Reflection
About Test Thread:
It's the first time to employ test thread for testing. It's not easy to handle it at the first time and I spent a lot of time to understand and design how to use it in a convenient way, especially for the IFTTT project. Also, this makes testing more difficult and time-consuming.
About Finding Bugs:
One of our ability nuturing in this course is the testing skills. It's very important for real life and it's a win-win to improve our coding skills. When coding, I would consider where the bugs might be hiding, what frame or structure would decrease bugs, how to use inner tools offered by Java to avoid thread safety problems, etc. During the debugging process, I would take notes of my bugs to help me test others' project. Besides, I would read testee's code to figure out their logic and find out which point is ignored.
About Communication:
This is also a very essencial part of this course. How to communicate when the tester and the testee have different opinions? How to make others understood yourself in the most precise way? How to solve the confliction is the smoothest way? These are all key problems when you're stepping into the society and working with others.
【5】About Course - To Myself and All of Us
This is not just a course. This is more like a small society. This course simulates an environment when you're in the workplace.
The testing platform makes you meet different people with different characters. Sometimes, your tester would be a nice person who report less bugs and communicate in a nice way. Sometimes, you feel like you're talking with someone who is totally different from you with different logic and different speaking habit. Sometimes, you witness things that is totally unfair in your own opinion but others would think in an opposite way. Sometimes happy yet sometimes angry.
But what I want to say is that it's all normal. When you step into the society, you would meet all kinds of people and all kinds of things. You can't make all the things happpen just as you want, since no one has the power to do it.
However, you should keep one thing in the mind: TO BE THE BEST OF YOURSELF and that's enough.
Don't do things that you think are wrong.
Don't forget your polite and moral upbringing.
Don't ignore injustice and unfairness even though you can't change the situation.