Java MultiThreading

[Guest1234]

I have a complex Java program. I am using MultiThreading.
I implement a Runnable interface.
for example:

myRunnable implements Runnable{

myRunnable(int i, int j){
//do soemthing
}

run(){
// do something
}

}

Main(vector v ){
int size = v.size(); //(which is 10)
myRunnable[] coco = null;

for(int i = 0;i<3;i++){
coco[i] = new myRunnable (i, j);
coco[i].start();
}
}


my query is...i have limit of 3 thread to be created but i have to run all the 10 objects. Now is there any way of Recurssion in Threads
For example :

run(){
if(something){
//change values in thread
start()
}
}

[r035198x]

I have a complex Java program. I am using MultiThreading.
I implement a Runnable interface.
for example:

myRunnable implements Runnable{

myRunnable(int i, int j){
//do soemthing
}

run(){
// do something
}

}

Main(vector v ){
int size = v.size(); //(which is 10)
myRunnable[] coco = null;

for(int i = 0;i<3;i++){
coco[i] = new myRunnable (i, j);
coco[i].start();
}
}


my query is...i have limit of 3 thread to be created but i have to run all the 10 objects. Now is there any way of Recurssion in Threads
For example :

run(){
if(something){
//change values in thread
start()
}
}

1.) Please use code tags everytime when posting code.
2.) What does vector v have to to with the threads? In the codes that you have posted (which obviously don't compile) there is no way to tell what you are trying to do. Perhaps if you describe your problem again or post the codes that are compiling and working.

[JosAH]

The way I read your question is: there are three threads and ten vectors that
need to be manipulated by three threads at the same time. I assume that when
a vector has been manipulated by a (single!) thread it doesn't need to be manipulated
again. I'd implement a shared resource: a bag of vectors to be manipulated.
Each thread competes to get and remove a vector from that bag. Once a vector
is obtained from the bag (and removed), the thread manipulates it and tries to
obtain a next vector from the bag. When the bag is empty, the thread dies.

A few synchronized methods in the Bag object (the shared resource) can do the
job for you.

kind regards,

Jos

[blazedaces]

The way I read your question is: there are three threads and ten vectors that
need to be manipulated by three threads at the same time. I assume that when
a vector has been manipulated by a (single!) thread it doesn't need to be manipulated
again. I'd implement a shared resource: a bag of vectors to be manipulated.
Each thread competes to get and remove a vector from that bag. Once a vector
is obtained from the bag (and removed), the thread manipulates it and tries to
obtain a next vector from the bag. When the bag is empty, the thread dies.

A few synchronized methods in the Bag object (the shared resource) can do the
job for you.

kind regards,

Jos

This brings up a question: if two threads are attempting to read and write a vector, what happens?

This kind of makes me think about my past classes, the reason for clocking and master-slave relationships between various components.

Shouldn't the program/threads be set up so that they can't manipulate the same set of data at any one time? Is this already implemented somehow through java?

Thanks for the knowledge,

-blazed

[JosAH]

This brings up a question: if two threads are attempting to read and write a vector, what happens?

This kind of makes me think about my past classes, the reason for clocking and master-slave relationships between various components.

Shouldn't the program/threads be set up so that they can't manipulate the same set of data at any one time? Is this already implemented somehow through java?

Thanks for the knowledge,

-blazed

That's an entirely different question. Vectors are synced on their add, remove, get,
size etc. methods, that's all. e.g. if two threads want to add elements to a vector
until the vector reaches some maximum size, those threads stillhave to do the
locking themselves; the vector class was ill-designed in that respect.

The OP's problem is simple: design a Bag class that hands out vectors in a synced
way to any thread that wants one; when the Bag is empty it'll return null. When
a thread can't obtain another vector from the Bag it dies, otherwise it processes
the vector (whatever that may be) and asks the Bag for another one afterwards.

kind regards,

Jos

[blazedaces]

That's an entirely different question. Vectors are synced on their add, remove, get,
size etc. methods, that's all. e.g. if two threads want to add elements to a vector
until the vector reaches some maximum size, those threads stillhave to do the
locking themselves; the vector class was ill-designed in that respect.

The OP's problem is simple: design a Bag class that hands out vectors in a synced
way to any thread that wants one; when the Bag is empty it'll return null. When
a thread can't obtain another vector from the Bag it dies, otherwise it processes
the vector (whatever that may be) and asks the Bag for another one afterwards.

kind regards,

Jos

In that case this bag class is a very good idea...

And thanks again for clearing that up, it's good to know, I'm very unfamiliar with multi-threading in any programming language.

-blazed

[r035198x]

That's an entirely different question. Vectors are synced on their add, remove, get,
size etc. methods, that's all. e.g. if two threads want to add elements to a vector
until the vector reaches some maximum size, those threads stillhave to do the
locking themselves; the vector class was ill-designed in that respect.

The OP's problem is simple: design a Bag class that hands out vectors in a synced
way to any thread that wants one; when the Bag is empty it'll return null. When
a thread can't obtain another vector from the Bag it dies, otherwise it processes
the vector (whatever that may be) and asks the Bag for another one afterwards.

kind regards,

Jos

This may be one of those few occasions where one might actually prefer to use a vector ?

[JosAH]

This may be one of those few occasions where one might actually prefer to use a vector ?

Not really; e.g. suppose you and I want to add elements to a vector until contains,
say, 10 elements; we still have to sync ourselves because the following doesn't
work:

[code=java]
if (v.size() < 10) {
// <--- danger here
v.add(<somethin g>);
}
[/code]

after checking for a legitimate size but before adding something to the vector
the other party might have added something to the vector already. Vectors are
useless for this purpose.

kind regards,

Jos

[r035198x]

Not really; e.g. suppose you and I want to add elements to a vector until contains,
say, 10 elements; we still have to sync ourselves because the following doesn't
work:

[code=java]
if (v.size() < 10) {
// <--- danger here
v.add(<somethin g>);
}
[/code]

after checking for a legitimate size but before adding something to the vector
the other party might have added something to the vector already. Vectors are
useless for this purpose.

kind regards,

Jos

Ok. I'd gotten the impression from the OP that he has a vector with objects already added and all they want to do is get the objects and perhaps manipulate them but without adding any more objects to the vector.
Of course the OPs never come back to clarify their problems ...

[JosAH]

Ok. I'd gotten the impression from the OP that he has a vector with objects already added and all they want to do is get the objects and perhaps manipulate them but without adding any more objects to the vector.
Of course the OPs never come back to clarify their problems ...

Yep; I do hope the OP replies again because I'm afraid I misunderstood the
question completely (although that little Bag trick works with any type of object)

We'll see ;-)

kind regards,

Jos

[r035198x]

Yep; I do hope the OP replies again because I'm afraid I misunderstood the
question completely (although that little Bag trick works with any type of object)

We'll see ;-)

kind regards,

Jos

Yep, I think the bag still forms the basis of the design unless they reply with something totally different.