Explore chapters and articles related to this topic
Multithreading in LabVIEW
Published in Rick Bitter, Taqi Mohiuddin, Matt Nawrocki, LabVIEW™ Advanced Programming Techniques, 2017
Rick Bitter, Taqi Mohiuddin, Matt Nawrocki
Effectively, a thread of execution is a miniature program running in a large, shared memory space. Threads are the smallest units that may be scheduled time for execution on the CPU and possess a call stack and set of CPU registers. The call stack is a first-in-first-out (FIFO) stack that is used to contain things like function calls and temporary variables. A thread is aware of only its own call stack. The registers are loaded into the CPU when the thread starts its execution cycle, and pulled out and loaded back into memory when the thread completes its execution time.
Blockchain-based ubiquitous manufacturing: a secure and reliable cyber-physical system
Published in International Journal of Production Research, 2020
Ali Vatankhah Barenji, Zhi Li, W. M. Wang, George Q. Huang, David A. Guerra-Zubiaga
To analyse the security of the platform, we simulated a major attack targeting the blockchain network. This attack permits control to be taken over the mining hashing power and thus enables other malevolent behaviours. For this purpose, we followed existing work in this area and we compare our result with the Bitcoin network (Moubarak, Filiol, and Chamoun 2018). Based on the case study, we consider 75 different nodes on the platform. The results of our simulation are given in Table 4. We demonstrated that a lower number of confirmations leads to a higher risk level. This type of attack is a consequence of other malevolent scenarios, such as stealing user machine power through Trojan system exploitation (Schaffner 2015), using a timestamp dependency attack to manipulate the mining or adding a call stack depth limit function and loops that can trigger the gas limit.
Algorithmic Improvements to MCNP5 for High-Resolution Fusion Neutronics Analyses
Published in Fusion Science and Technology, 2018
Scott W. Mosher, Stephen C. Wilson
In a multithreaded application, each executing thread has the same view of memory except for the thread’s local call stack and any data that are explicitly declared to be private to each thread. This is a key advantage of multithreading over MPI-based parallelism. Multithreading enables memory-efficient algorithms where large data structures are shared by all threads. In MCNP, for example, all threads access a shared copy of the continuous-energy cross sections and space- and energy-dependent weight-window parameters. When using shared memory for mutable data structures, such as mesh tally data, care must be taken to avoid race conditions. A race condition occurs when two or more threads access the same memory location concurrently and at least one of the accesses changes the stored value. The result of reading the data is then dependent on the order in which the instructions of the various operating threads happen to be executed. This type of condition can produce unexpected and incorrect results and can even lead to memory corruption. Care must also be taken to avoid thread synchronization errors, which can cause the program to deadlock when two or more threads are blocked waiting for each other to perform some action.
Mixed-language automatic differentiation
Published in Optimization Methods and Software, 2018
Valérie Pascual, Laurent Hascoët
We believe that every mixed-language parameter-passing strategy used with Fortran and C can boil down to a few simple behaviours at the time of entry into and return from the called procedure. At call time, we define what we call the passed argument, which may be the actual argument, or the memory pointed to by the actual argument, or conversely the address of the actual argument, depending on the mixed-language strategy that must be captured. Then the internal memory corresponding to this passed argument is copied into the internal memory corresponding to the called procedure's formal argument. At return time, the internal memory corresponding to the formal argument may be either copied back to the actual parameter or not copied in which case it will vanish when the called procedure is popped from the call stack. When there is a back copy, it follows the link from the passed argument back to the actual argument: if they are the same, the copy is written into the actual argument, and if the passed argument is the destination of the actual, then the copy is written at the address designated by the actual argument.