NotAfraidOfWong

This is a recap conclusion to the potential problems of a NodeJS program I worked on previously. The program simulates thousands of clients navigating a website by sending thousands of http requests to a given API . The idea is to load test a particular API to make sure they can handle high traffic. Because we are simulating clients, it's important to keep track of the state of the simulated client as well. The problem with this program is it is buggy and becomes unresponsive from time to time (the only solution is to restart it). The problem was fixed by re-writing the entire program in Java, but it was regretful that I never had enough time to find the exact reason the nodeJS version of it failed. The following are potential causes I suspect: 1. Exceptions The NodeJS program was not written very neatly and stacked callbacks on top of callbacks on top of callbacks. This made it very difficult to keep track of exceptions and unexpected http responses are prone to happen. So...

1) Volatile Used as an indicator to Java Compiler and Thread to not cache value of this variable and always read it from the main memory . In multi-threaded environment, threads might cache variables locally. Volatile (or synchronization) ensures the variable is read from main memory. Makes variable atomic by implementation.  Only possible with variables ; cannot be used with method or class (illegal operation) Guarantees visibility and ordering; write to any volatile variable happens before any read. Prevents compiler or JVM form reordering code or moving away them away form synchronization barrier.  2) Example private boolean bExit ; while (! bExit ) { checkUserPosition (); updateUserPosition (); } The focus here is the variable, bExit.  One Thread (Game Thread) can cache the value of bExit instead of getting it form main memory everytime. If in between, any other thread (Event handler thread) changes the value; it would...

1) Reentrant Lock Implementation of Lock interface.  Mutually-exclusive lock (similar to synchronized) with extended feature like fairness. Lock is acquired via lock() and is held until unlock() 2) Reentrant Lock vs Synchronized 2.1) Blocking Indefinitely vs Temporarily/Selectively. Main difference is reentrant lock has the ability to try to lock interruptibly and with timeout. tryLock() allows program to try the lock without being blocked. In summary, Thread doesn't need to blocked indefinitely, whereas synchronized block block indefinitely. 2.2) Fairness Supported by Reentrant lock, but not by synchronized. 2.3) Get List of Threads waiting for Lock Reentrant locks have ability to see all threads waiting on the lock; accessible via API. 3) Cons of Reentrant Lock 3.1) Readability Requires wrapping in try-finally block, which makes code unreadable and hides business logic. 3.2) Potential Bugs Programmer is now responsible for acquiring and releasing loc...

1) Start Approach The short and quick answer is to have # threads = CPU/Cores. Why have a thread if there's nothing to run it? Therefore, one thread per process/core will maximize processing power and minimize context switching. This assumption is a good starting approach . public static final int THREADS = Runtime . getRuntime (). availableProcessors (); 2) Detailed Approach: CPU-bound or I/O bound? But the more correct answer is - it depends if your task is  CPU-bound or I/O-bound? 2.1) I/O-bound If your thread has to wait for network packet or disk block, then CPU time is wasted waiting. In this case, you will want to consider having more threads per process, as your program can work on another thread instead of just waiting. However, there is an overhead of adding threads and additional work that will get accomplished. 2.2) CPU-bound But if your thread is CPU heavy, then a 1:1 correlation makes more sense, because adding more threads will only slow...

Parallel Computing =/= Concurrent Computing. What is threading? Parallel computing is a type of computation in which many calculations or the execution of processes are carried out simultaneously . Large problems can often be divided into smaller ones, which can then be solved at the same time. There is no taking turns, they are advanced at the same time. Naturally this is not possible with single-core CPU, but multiple-core architecture is required instead. It can be said that if computation is parallel it is also concurrent (but not necessarily the other way around) - since parallel computation also fulfills the definition of concurrent computation. Concurrent computing is a form of computing in which several computations are executed during overlapping time periods — concurrently —instead of sequentially (one completing before the next starts). This is not exactly same as Parallel computing . Concurrent operation means that two computations can both make progress an...