Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Wikipedia defines an execution unit as:
"In computer engineering, an execution unit (also called a functional unit) is a part of a CPU that performs the operations and calculations called for by the computer program."
Now, is it a logical or conceptual thing performing the operations of the program? Or is it a physical (hardware) structure in CPU which performs the tasks called for by the program (e.g. shutting down the computer, changing the colors etc. ) ?
And I have read that "In concurrent programming, there are two units of execution i.e. processes and threads."
Now, the concept I have made in my mind is that a unit of execution is, let's say a package of related classes as well as the system resources being used by them e.g. system's memory and other resources.
Please tell me to what extent am I right?
NOTE: Please keep your language (i.e. jargon and terminology you might use) simple enough for a beginner to understand.
Thank you in advance.
It appears to me that execution unit refers to hardware, specifically a portion of the computer's brain that can work at the same time as other parts on a different task. It seems to allow simple multi-tasking, as implied by Wikipedia's article on the execution unit. The article explains that Superscalar Architecture involves multiple execution units fetching commands at the same time.
An execution unit is like a worker. He has a job and does it until he is finished. Then he asks his boss what to do next and works on that. When you have multiple workers, you get more work done faster. An execution unit does low level tasks like 1+1.
Moving onto unit of execution, it appears this is more about how the software runs, as evidenced by this microsoft article. A unit of execution, such as a thread, manages high level tasks involving many small steps like conquerTheWorld().
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I am having Windows system running on several processor cores (physical as well as logical). As far as my understanding goes for Java threads, threads run as light-weight processes sharing the memory (heap and global area) of the JVM process. Each concurrently running thread has a separate non-shareable stack and we assign a method to be run as part of the thread execution. While we manage synchronization for shared resources (memory, file handle, database connection etc), we have different code execution with separate call stack of data. Now, first question is, do I have a control to run threads on different processor cores,if available. If not, then I could be under-utilizing my processor capacity having one processor core heavily loaded and other processor cores under utilized. Can that be controlled through compilation flags of javac and subsequently java jvm flags?
Next part of question is regarding java parallel stream. Since I have heavy duty input and output streaming operations, mostly independent of each other, in terms of content as well as chronology of executions. This demands to use parallel stream, ideally scheduled on different processor core to gain execution speed. Any suggestions/pointers?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
For the past few weeks now I've been studying Concurrency(Multithreading) in Java. I find it difficult and rather different than anything I've encountered in the Java language so far(or in programming in general). Often I have to reread and reread over and over again until I start to understand a small concept fully.
It's frustrating and I've wondered why this part of the Java programming language has given me so much trouble.
Usually when I look at the code of a single-threaded program I look at the main method and start going step by step in my mind through the whole execution(like a debugger). Throughout this process I try to keep in mind EVERYTHING like variables and their states(values) at every point in the execution. Often times when doing that I even stop at certain points and think how the program execution would alter in different scenarios. If I can go through a program from start to finish like that, I feel like I've fully understood the code and the material.
The problem that I have, I suppose, is that when I try to apply this method for a concurrent application, there are so much things happening at once(sleep(), synchronized methods, acquiring intrinsic locks, guarded blocks using wait(), etc.) and there's so much uncertainty of when something will execute, that it becomes nearly impossible for me to keep up with everything. That's what frustrates me, because I want to have a feeling of "I have control over what's happening", but with concurrency that's impossible.
Any help would be appreciated!!!
Concurrency is a simple concept, really - you have several separate paths of execution, which can interact with each other. The stuff you mentioned, like syncing, blocks, waits and so on are technical details, tools.
I would suggest trying to do some coding :-) Come up with a multi-thread program idea and code it. At some point you will need to use one of the tools you listed and it will all begin to fall into place. This is NOT a concept you should to understand only in theory ^^
More over a Science, Concurrent Programming is an art.
Before going into Java concurrency, PLEASE DO go through the conceptual things first.. i.e. what are the major problems in concurrency? what is a lock? what is a semaphore? what is a barrier? why we are using those? how can we use them for different purpose like variable protection, synchronization etc.? Likewise there are some.
Then you would probably get some very important knowledge before getting into language specific usage.
For a person who have followed sequential programming all the time and first looking at concurrency, definitely it would be harder to understand those things at once. But I am sure you can go to the level that you are in sequential programming for concurrent programming also after some time. :))
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am new to zookeeper, Apache curator and need your help to design a prorgram:
I need to create a java program, that will run a script every hour (based on cron expression provided by end user).
Consider I have 3 servers, I need to make sure the script runs every hour without failure even in case of a server is down (in this case script must run on other server). Every hour script will be running only on one server.
I have to create an interface to provide input the this java program. Input will be (i) Script to be run and (ii) Cron expression to schedule script.
1) Please suggest an idea how can I design my program to achieve this. How zookeeper, Apache curator can be used in the same.
2) Is there any way to cache the script on these 3 servers that end-user provide to run?
Can Apache curator's NodeCache be used to cache the script on these 3 servers?
Your response will be highly appreciated.
With three servers, where one is to run no matter what, you need a distributed approach. The problem is that in the event of failures, you might not be able to solve the puzzle of whether to run the script or not.
For a start, you can just have one computer connect to others and tell them not to run. This is called a "hold down" approach; but, it has a lot of issues when you can't connect to the other computers. The problems are that most starting programmers fail to really understand the changes a network environment makes on how they need to design programs. Please take a little time to read over the typical fallacies of distributed computing.
Chron solves this by not caring what happens on other computers, so chron has the wrong design goals.
With three computers, you will also have three different clocks, with their own speeds and times. A good distributed solution will have some concept of time that doesn't directly rely on each machine's clock.
Distributed solutions (if they are to tolerate faults or failures) must be able to run without reliable communication to the other machines. Sometimes the group gets split in half, where one group of machines cannot communicate to the other group. In many cases, both group will perform the "critical" action in fear that the other group didn't. It other cases, both groups might not perform the "critical" action assuming that the other group did. A good solution will ensure that the "critical action" is performed once, even when the computers cannot communicate. Often this is done by "majority" where your group (quorum) cannot perform a critical action if you don't have access to at least a majority of the involved machines.
Look at the Paxos algorithim to get an idea of the issues; and, once you are more aware of the problems, look back at your chosen technologies to determine which parts of the problems they are attempting to solve considering the "fallacies of distributed computing". Also realize that a perfect, 100% correct solution might not be possible; because, the pre-selected machine(s) to run the script might suffer a network failure, and then a power failure in sequence in such a manner that the up machines just assume there's only a network outage.
This is an interview question, right? If yes, be aware that this answer only gets you partway.
The simplest solution is to have all three servers running, and attempt to acquire a lock to perform the processing. See http://zookeeper.apache.org/doc/trunk/recipes.html#sc_recipes_Locks
To ensure that only one server runs the job, you will need to record the last execution time. This is simply "store a value with known key," and you'll find it in one of the intro tutorials.
Of course, if this is an interview question, the interviewer will ask follow-on questions such as "what happens if the script fails halfway through?" or "what if the computers don't have the same time?" You won't (easily) solve either of those problems with ZooKeeper.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
In many examples that discuss synchronization, it is mentioned something to the effect, "This will work in a single-threaded application, but if multi-threaded..."
I am puzzled because it seems to me possible, although perhaps incredibly unlikely, that even in a single-threaded operation, there can be problems similar to those mentioned in multi-threaded applications.
Say you have an object that has a status field that reflects whether it has been placed into a queue. Pseudo-code would be: object.setStatus(INQUEUE); placeInQueue(object);
Now, if it was somehow possible for the status to be successfully set but the next line of code "silently fail" and the program continue, would we not have a problem wherein we think the object is in the queue but is not? Maybe the idea that we could have a silent failure is false.
But if it is somehow possible for the above problem to occur, how would we make so that the two lines of code either always both executed or both failed?
Logic bugs, that is a flaw in the algorithm, can and regularly do still happen in single threaded applications. If such a problem exists in a single threaded implementation of the algorithm, then it will only get worse when one tries to make it multi-threaded.
The quote "This will work in a single-threaded application, but if multi-threaded..." was talking about a class of problem that gets introduced by the nature of being concurrent. For example, if I was in the kitchen baking a cake by myself I would not have to worry about bumping into another chief. I would however have to still worry about burning my hands on the oven and not bumping my hip on the counter.
The scenario that you describe using a queue, that is backed by disk is another example of parallelism. Even though our application logic is single threaded, other processes can be writing to disk while our process is working with the queue and so it is possible for the disk to run out of space at no fault of our program. Handling such problems can become quite involved, the two basic approaches are to either lock out a resource for a period of time or optimistically assume that one will succeed and then handle an error when it fails later. The example that you gave was an example of the later, only without the error handling. A silent failure in that scenario can happen in real systems that ignore the problem, and they are broken.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
After coming across the concept of co-routines in Lua I feel that these seem to be a much better model for programming concurrent software and i'm wondering why there was not used in Java?
Co-routines seem to let the developer write code which jumps between multiple functions, progressing each a few steps at a time, providing the illusion of concurrent execution, in much the same way as the CPU would time slice between multiple threads in Java, however co-routines allow the developer to decide when to jump out of one function and start executing another. This allows the developer to decide how fine grain the steps should be, ie the degree of concurrency, and when the context switch should occur, which could prevent costly context switches when latency is critical.
Coroutines are powerful but will not replace full fleged multithreaded applications, because coroutines run on a single thread. As such they will not make use of multiple cores when needed for CPU intensive tasks. I see them as representing a complementary paradigm rather than a competing one. Functional programing is making a headway into Java as it has already done on the .Net platform. Coroutines will eventually follow suite. I suggest you to look at the Java roadmap for more info.
See Processes, threads, green threads, protothreads, fibers, coroutines: what's the difference? for a more elaborate answer that covers coroutines and other concepts.
See also Throughput differences when using coroutines vs threading that discusses the implementation of the producer consumer problem with coroutines instead of multiple threads.