Develop Reference

Defining Multiple Threads in Java

I am writing a program that reads words from a file and sorts them in alphabetical order. You provide the input and output files in the command line, and the program reads the words from the input file and writes a sorted list back to the output file. This is done, and it works as it should do. No questions here.
I am not looking for specific code, but rather help on how to approach a problem. The next part of the assignment states that in the command line, you are to be able to set the number of Threads you want the program to use in the sorting process.
For instance, if you compile with the following:
java Sort 12 infile.txt outfile.txt
The above program is meant to use 12 Threads to sort the words from "infile.txt". Each Thread is to sort a number of N = (numberOfWords)/(numberOfThreads) words. All the words are read into memory, before the Threads are started. I'm aware that this might sound cryptic, but I have been googling around looking for a good explanation on "multithreading"/defining the number of Threads in a Java program, yet I am not any wiser.
If anyone knows how to explain how you can set the number of Threads in Java, even with a small example, I would be very grateful!
Thanks!

You could use the Executors.newFixedThreadPool(int nThreads) method (see details here) to get a ThreadPool with the required number of threads. Then, divide your work into the appropriate number of chunks (12 in your example), create a Runnable object for each chunk of work and pass those Runnable objects to the ThreadPool's submit method.

Oh sure. Well a thread is just a class with a "run" method.
You create the class and either have it extend Thread or implement Runnable. If you extend thread you can just call Thread.start() on it and that would start the thread. If you implement Runnable instead you have to so something like Thread t = new Thread(yourRunnableClass);, and then start T.
So for your example:
public class Sort {
class RunnableClass implements Runnable(){
String args;
RunnableClass(String[] args){
this.args = args;
}
run(){
//Do your sorting
}
}
public static void main(String[] args){
//some code that chops the args beyond arg 0 into arrays or something
int numberOfThreads = Integer.parseInt(args[0]);
for(int x=0;x<numberOfThreads;x++){
Thread t = new Thread(new RunnableClass(String[] wordsToSort));
}
//something to manage the threads and coordinate their work
}
}
You could make this more elaborate or complex, one simple implementation would be to just loop over the words, passing 2 to each thread to sort and then once the threads complete if the order didn't change increment along the list till no orders change. That's a form of bubble sort. So in other words Thread A sorts words 1 and 2 Thread B sorts words 3 and 4 and so on.
The threads can communicate with each other, share state or have their own state, etc. There are many ways to implement this.
The threads could terminate, or be re-entrant, could have state, etc.

Executors class has static newFixedThreadPool (int numberOfThreads) that can be given the number of threads to pool. For example, if you have class implementing Runnable
public class MyCustomThread implements Runnable {
#Override
public void run() {
//do your work
}
}
you can create pool with 5 threads like this
..
int numberOfThreads = 5;
ExecutorService srv = Executors.newFixedThreadPool(numberOfThreads);
for (int i = 0; i < numberOfThreads; i++) {
srv.execute(new MyCustomThread());
}
Using ExecutorService it will be much easier for you to manage lifecycles of threads. Read Oracle concurrency tutorial for more information.

Here I want to ask you one question is which version of java you are using. As this task is not trivial to achieve as you are required to take care of couple things like threads join etc. Java 7 has a feature 'Fork/Join' by which you can leverage the task.
You can refer the following for an example.
Sorting using Fork/Join
You can start from this

What you're looking for is a Fork/Join framework. This splits a single task into parts, handing the parts to multiple threads to be processed.
ExecutorService's FixedThreadPool allows you to create 12 worker threads, but leaves you with all the hard work of separating the work between the threads. The Fork/Join framework makes this easy, using a recursive system to break the process down if needed so it could be split between threads.
http://docs.oracle.com/javase/tutorial/essential/concurrency/forkjoin.html

define a runnable, then in a loop add new threads with that runnable to a list. then start all the threads, either in the same loop or a separate one, passing all the words you need to process to each runnable on construction?
you will also have to control access to the output file, and possibly the input file depending on how you access it, otherwise your thread will run into trouble, so take a look at race-conditions and how to deal with them

java concurrency - synchronized block

I have a thread issue in my code that should not be happening - but is. So I'm trying to make some work around. I will try to explain my problems with simple code as I can - because the code that I'm experiencing the issue is big and complicated
so in short the code:
...................
..................
void createAndRunThreads(){
List<Path> pathList = //read path from DB readPath();
for(Path p : pathList){
RunJob rj = new RunJob(p);
Thred t = new Thread(rj);
t.start();
}
}
class RunJob implements Runnable {
private Path path;
private ExecuteJob execJob;
public RunJob(Path path){
this.path = path;
this.execJob = new ExecuteJob();
}
public void run() {
execJob.execute(path);
}
}
class ExecuteJob {
private static Job curentExecutingJob;
public void execute(Path path){
//here every thread should get different job list from others but this is not happening
//so what happens eventually two threads are executing the same Job at once and it gets messy
List<Job> jobList = getJobsFromPath(path);
for(Job job : jobList) {
curentExecutingJob=job;
//work around that I'm trying to do. So if other thread tries to run the same job has to wait on lock(I dont know if this is posible do)
synchronized(curentExecutingJob){
if(job.getStatus.equals("redy")){
//do sum initialization
//and databese changes
job.run();
}
}
}
}
}
So my concern is if this going to work - I don know if the object in the lock is compared by memory(need to be the exact object) or by equals(to implement equal on it)
What happens when the static curentExecutingJob member has one value-object in first thread and creates lock on that(in synchronized block) and second thread changes that value and tries to enter synchronized block(My expectation that I'm hoping to be is that thread-2 will continue with executing and only time that it would be block is when he will get the same Job from DB that previously the first thread got it)
I don't know if this approach can be done and has sense
Two thread are running the following code that is inside method
1 Job j = getJobByIdFromDB(1111);
2 if(j.status.equals("redye")){
3 do staff
4 make database changes
5 j.run();
6 j.state="running";
7 }
The ThreadA is stop from executing in line 3 from JVM and his state is changed from running to runnable and is set to wait in the poll.
The ThreadB is given chance by the JVM and ThreadB executes lines 1, 2, 3, 4, 5, 6 that I don't want to happen. I want the first thread that enters the code in lines 2,3 to finish before someone from the rest threads have chances to enter the same code
Problem accomplish this is that the two threads are executing the example method with different instance so synchronized the whole method wont work - also I have other code that is been executed in this method and I don't want that to be synchronizing to
So is there solution for my problem
Also if I make synchronized(this.class){} it will lose the benefits and sense of multithreading

The problem is that the 'currentExecutingJob' is defined as static, meaning that all instances of ExecuteJob share the same 'instance' of this variable. In addition, you are setting the value of this variable outside of a synchronization block, which means that each thread will set it in an uncontrolled way. Your following synchronization block should have no practical impact whatsoever.
Given the way your sample code is written, it appears to me that you don't need any static variables and you don't need any synchronization, as there are no resources shared across multiple threads.
However, Your comments in the code indicate that you want to prevent two threads from executing the same job at the same time. Your code does not achieve this, as there is no comparison of running jobs to see if the same job is running, and even if there was a comparison, your getJobsFromPath() would need to to construct a job list such that the same object instance would need to be reused when two threads/paths encounter the same 'job'.
I don't see any of this in your code.

Can't comment so I'll put it as an answer. Sorry.
The block
synchronized(curentExecutingJob)
will synchronize on the object curentExecutingJob (in your terms, memory). If you synchronize on another object otherExecutingJob with currentExecutingJob.equals(otherExecutingJob) == true, both synchronize statements will not influence each other.
To your question/problem: It would be helpful if you describe what getJobsFromPath is doing or should do and what you actually want to do and what your problem actually is. It's not really clear to me.

i saw your code that it check's for the status of job, if it is ready or not, well as i think this is not a afeasible way
you can use the Callable Interface instead of Runnable
here is an example detailed which may help you.
Java Concurrency

converting a utility class to multithreaded class

I have a utility class in Java which is accessing a big file system to access a file.
Some files are huge so whats happening is that the Utility class is talking a lot of time to access these files and i am facing a performance issue here.
I plan to implement Multithreading to improve performance but i am bit confused as to how i need to do that. below is the structure of the Utility class.
public class Utility {
public static void Method1(ArrayList values){
//do some processing
for(int i=0; i< values.size();i++){
ArrayList<String> details= MethodAccessFileSystem();
CreateFileInDir(details);
}
}
public ArrayList<String> MethodAccessFileSystem(){
//Code to access the file system. This is taking hell lot of time.
}
public void CreateFileInDir(ArrayList<String> values){
//Do some processing here.
}
}
I used to call this Utilty class in a standalone class using the following syntax
Utility.Method1(values); //values is an ArayList.
Now i need to convert the above code into a Multithreaded code.
I know how to create a thread by extending Thread class or implementing a Runnable.
I have a basic idea about that.
But what i need to know is should i convert this whole Utilty class to implement Runnable.
or should parts of the Utilty class needs to seperated and made as Runnable task.
My issue is with the for() loop as these methods are called in loop.
if i separate out MethodAccessFileSystem() and make it as a task will this work.
If MethodAccessFileSystem() is taking a time then will the JVM automaticaly start another thread if i use a Threadpoolexecutor to schedule a fixed number of threads.
Should i need to suspend this method or it is not required or JVM will take care.
The main issue is with the For loop.
At the end what i need is that the Utility class should be Multithreaded and the call to method should be the same as the above.
Utility.Method1(values); //values is an ArayList.
I am thinking as to how i can implement that.
Can you please help me with this and provide your suggestions and feedback on the design changes that need to be made.
Thanks
Vikeng

From your class According to me the chunk of work which fits in Parallelism principle is below loop.
// do some processing
for (int i = 0; i < values.size(); i++) {
new Thread(new Runnable() {
#Override
public void run() {
ArrayList<String> details = MethodAccessFileSystem();
CreateFileInDir(details);
}
});
}

Before you make the change make sure that multiple threads will help. Run the method and as best you can check CPU and disk i/o activity. Also check to see if there's any garbage collection going on.
If any of those conditions exist then adding threads really won't help. You'll have to address that specific condition in order to get any throughput improvements.
Having said that the trick to making the code thread safe is to not have any instance variables on the class that are used to hold state during the method execution. For each existing instance variable, you need to decide whether to make it a local variable declared within the method or a method parameter.

How to test visibility of values between threads

What is the best way to test value visibility between threads?
class X {
private volatile Object ref;
public Object getRef() {
return ref;
}
public void setRef(Object newRef) {
this.ref = newRef;
}
}
The class X exposes a reference to the ref object. If concurrent threads read and and write the object reference every Thread has to see the latest object that was set. The volatile modifier should do that. The implementation here is an example it could also be synchronized or a lock-based implementation.
Now I'm looking for a way to write a test that informs me when the value visibility is not as specified (older values were read).
It's okay if the test does burn some cpu cycles.

The JLS says what you are supposed to do in order to get guaranteed consistent execution in an application involving "inter-thread actions". If you don't do these things, the execution may be inconsistent. But whether it actually will be inconsistent depends on the JVM you are using, the hardware that you are using, the application, the input data, and ... whatever else might be happening on the machine when you run the application.
I cannot see what your proposed test would tell you. If the test shows inconsistent executions, it would confirm the wisdom of doing synchronization properly. But if running the test a few time shows only (apparently) consistent executions, this doesn't tell you that executions are always going to be consistent.
Example:
Suppose that you run your tests on (say) JDK 1.4.2 (rev 12) / Linux / 32bit with the 'client' JVM and options x, y, z running on a single processor machine. And that after running the test 1000 times, you observe that it does not seem to make any difference if you leave out the volatile. What have you actually learned in that scenario?
You have NOT learned that it really makes no difference? If you change the test to use more threads, etc, you may get a different answer. If you run the test a few more thousand or million or billion times, you might get a different answer.
You have NOT learned anything about what might happen on other platforms; e.g. different Java version, different hardware, or different system load conditions.
You have NOT learned if it is safe to leave out the volatile keyword.
You only learn something if the test shows a difference. And the only thing that you learn is that synchronization is important ... which is what all of the text books, etc have been telling you all along :-)
Bottom line: this is the worst kind of black box testing. It gives you no real insight as to what is going on inside the box. To get that insight you need to 1) understand the Memory Model and 2) deeply analyze the native code emitted by the JIT compiler (on multiple platforms ...)

If I understand correctly, then you want a test-case that passes if the variable is defined as volatile and fails if not.
However I think there is no reliable way to do this. Depending on the implementation of the jvm concurrent access may work correctly even without volatile.
So a unit test will work correctly when volatile is specified but it still might work correctly without volatile.

Wow, that's much tougher than I initially thought.
I might be completely off, but how about this?
class Wrapper {
private X x = new X();
private volatile Object volatileRef;
private final Object setterLock = new Object();
private final Object getterLock = new Object();
public Object getRef() {
synchronized(getterLock) {
Object refFromX = x.getRef();
if (refFromX != volatileRef) {
// FAILURE CASE!
}
return refFromX;
}
}
public void setRef(Object ref) {
synchronized(setterLock) {
volatileRef = ref;
x.setRef(ref);
}
}
}
Could this help?
Of course, you will have to create many Threads to hit this wrapper, hoping for the bad case to appear.

How about this ?
public class XTest {
#Test
public void testRefIsVolatile() {
Field field = null;
try {
field = X.class.getDeclaredField("ref");
} catch (SecurityException e) {
e.printStackTrace();
Assert.fail(e.getMessage());
} catch (NoSuchFieldException e) {
e.printStackTrace();
Assert.fail(e.getMessage());
}
Assert.assertNotNull("Ref field", field);
Assert.assertTrue("Is Volatile", Modifier.isVolatile(field
.getModifiers()));
}
}

So basicaly you want this scenario: one thread writes the variable, while another reads it at the same time, and you want to ensure that the variable read has the correct value, right?
Well, I don't think you can use unit testing for that, because you can't ensure the right environment. That is done by the JVM, by how it schedules instructions. Here's what I would do. Use a debugger. Start one thread to write the data and put a breakpoint on the line that does this. Start the second thread and have it read the data, also stopping at that point. Now, step the first thread to execute the code that writes, and then read with the second one. In your example, you won't achieve anything with this, because read and write are single instructions. But usually if these operations are more complex, you can alternate the execution of the two threads and see if everything is consistent.
This will take some time, because it's not automated. But I wouldn't go and write a unit test that tries reading and writing a lot of times, hoping to catch that case where it fails, because you wouldn't achieve anything. The role of a unit test is to assure you that code you wrote is working as expected. But in this case, if the test passes, you're not assured of anyhing. Maybe it was just lucky and the conflict didn't appera on this run. And that defeats the purpose.

calling thread.start() within its own constructor [duplicate]

This question already has answers here:
Java: starting a new thread in a constructor
(3 answers)
Closed 6 years ago.
is it legal for a thread to call this.start() inside its own constructor? and if so what potential issues can this cause? I understand that the object wont have fully initialized until the constructor has run to completion but aside from this are there any other issues?

For memory-safety reasons, you shouldn't expose a reference to an object or that object's fields to another thread from within its constructor. Assuming that your custom thread has instance variables, by starting it from within the constructor, you are guaranteed to violate the Java Memory Model guidelines. See Brian Goetz's Safe Construction Techniques for more info.

You will also see wierd issues if the Thread class is ever further subclassed. In that case, you'll end up with the thread running already once the super() exits, and anything the subclass might do in its constructor could be invalid.
#bill barksdale
If the thread is already running, calling start again gets you an IllegalThreadStateException, you don't get 2 threads.

I assume that you want to do this to make your code less verbose; instead of saying
Thread t = new CustomThread();
t.start();
activeThreads.add(t);
you can just say
activeThreads.add( new CustomThread() );
I also like having less verbosity, but I agree with the other respondents that you shouldn't do this. Specifically, it breaks the convention; anyone familiar with Java who reads the second example will assume that the thread has not been started. Worse yet, if they write their own threading code which interacts in some way with yours, then some threads will need to call start and others won't.
This may not seem compelling when you're working by yourself, but eventually you'll have to work with other people, and it's good to develop good coding habits so that you'll have an easy time working with others and code written with the standard conventions.
However, if you don't care about the conventions and hate the extra verbosity, then go ahead; this won't cause any problems, even if you try to call start multiple times by mistake.

By the way, if one wants lower verbosity and still keep the constructor with its "standard" semantics, one could create a factory method:
activeThreads.add( CustomThread.newStartedThread() );

It's legal, but not wise. The Thread part of the instance will be completely initialised, but your constructor may not. There is very little reason to extend Thread, and to pull tricks like this isn't going to help your code.

It is "legal", but I think the most important issue is this:
A class should do one thing and do it well.
If your class uses a thread internally, then the existence of that thread should not be visible in the public API. This allows improvement without affecting the public API. Solution: extend Runnable, not Thread.
If your class provides general functionality which, in this case, happens to run in a thread, then you don't want to limit yourself to always creating a thread. Same solution here: extend Runnable, not Thread.
For less verbosity I second the suggestion to use a factory method (e.g. Foo.createAndRunInThread()).

Legal ... yes (with caveats as mentioned elsewhere). Advisable ... no.
I's just a smell you can only too easily avoid. If you want your thread to auto-start, just do it like Heinz Kabutz.
public class ThreadCreationTest {
public static void main(String[] args) throws InterruptedException {
final AtomicInteger threads_created = new AtomicInteger(0);
while (true) {
final CountDownLatch latch = new CountDownLatch(1);
new Thread() {
{ start(); } // <--- Like this ... sweet and simple.
public void run() {
latch.countDown();
synchronized (this) {
System.out.println("threads created: " +
threads_created.incrementAndGet());
try {
wait();
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}
}
};
latch.await();
}
}
}