ThreadPoolExecutor - thread creation madness

Hi all,
I am trying to use a Thread Pool for a task server. My testing involves running 10 concurrent jobs that each serially call the server 100 times.
The maximum load on the server (for this test) is therefore 10 tasks at any given point in time. The Thread Pool is creating between 50 and 100 threads to process these tasks. I sent all morning looking at the source and cannot figure out why these threads are being created. Existing threads should be re-used.
The pool is created with 5 core, 100 max threads, 60sec lifetime and a task Q of 5.
The server simply listens to a port (Socket) and calls .execute when a task arrives.
Any ideas why so many threads are being created ?
Thanks,
Craig.

Here are stats from a run with Core=10, Max=50, Lifetime=60 and Q=6.
The maximum number of threads was reached and tasks were rejected. As per previous post, there was a maximum of 10 concurrent tasks at any given point in time (see Max Act column).
Thread Summary
Max Act (max number of active threads), Max Q (max tasks in Q),
Min/Max PlSz (min/max pool size) are all taken from snapshots while the
reported thread was executing a task.
                                                    Times Max Max Min Max   1st   Last
Thread First Used           Last Used               Used Act   Q PlSz PlSz Task Task
    12 2007-07-18 14:36:29 2007-07-18 14:37:19       24   10    0   10   50    11   963
    13 2007-07-18 14:36:29 2007-07-18 14:37:20       25   10    0   10   50    12   970
    14 2007-07-18 14:36:28 2007-07-18 14:37:19       25   10    0   10   50     3   956
    15 2007-07-18 14:36:29 2007-07-18 14:37:20       26   10    0   10   50     4   983
    16 2007-07-18 14:36:29 2007-07-18 14:37:23       26   10    0   10   50     5 1002
    17 2007-07-18 14:36:29 2007-07-18 14:37:19       25   10    0   10   50     6   962
    18 2007-07-18 14:36:29 2007-07-18 14:37:21       25   10    0   10   50     7   991
    19 2007-07-18 14:36:29 2007-07-18 14:37:20       25   10    0   10   50     8   965
    20 2007-07-18 14:36:29 2007-07-18 14:37:20       27   10    0   10   50     9   975
    21 2007-07-18 14:36:29 2007-07-18 14:37:22       26   10    0   10   50    10 1000
    22 2007-07-18 14:36:31 2007-07-18 14:37:25       24   10    0   11   50    32 1007
    23 2007-07-18 14:36:32 2007-07-18 14:37:20       22   10    0   16   50    46   978
    24 2007-07-18 14:36:32 2007-07-18 14:37:20       21   10    0   16   50    47   977
    25 2007-07-18 14:36:32 2007-07-18 14:37:20       22   10    0   16   50    48   973
    26 2007-07-18 14:36:32 2007-07-18 14:37:20       22   10    0   16   50    49   980
    27 2007-07-18 14:36:32 2007-07-18 14:37:21       24    9    3   16   50    50   992
    28 2007-07-18 14:36:34 2007-07-18 14:37:20       20   10    0   18   50    76   968
    29 2007-07-18 14:36:34 2007-07-18 14:37:21       20   10    0   18   50    77   989
    30 2007-07-18 14:36:34 2007-07-18 14:37:20       18   10    0   20   50    91   976
    31 2007-07-18 14:36:34 2007-07-18 14:37:19       19    9    0   20   50    92   959
    32 2007-07-18 14:36:35 2007-07-18 14:37:22       19   10    0   22   50   103   995
    33 2007-07-18 14:36:35 2007-07-18 14:37:21       19   10    0   22   50   104   984
    34 2007-07-18 14:36:37 2007-07-18 14:37:24       18   10    0   23   50   129 1005
    35 2007-07-18 14:36:38 2007-07-18 14:37:21       15    9    0   27   50   162   993
    36 2007-07-18 14:36:38 2007-07-18 14:37:24       18   10    1   27   50   163 1004
    37 2007-07-18 14:36:38 2007-07-18 14:37:24       16   10    0   27   50   164 1006
    38 2007-07-18 14:36:38 2007-07-18 14:37:20       16   10    0   27   50   166   967
    39 2007-07-18 14:36:39 2007-07-18 14:37:20       16   10    0   32   50   176   982
    40 2007-07-18 14:36:39 2007-07-18 14:37:21       16    9    0   32   50   177   988
    41 2007-07-18 14:36:39 2007-07-18 14:37:20       16   10    0   32   50   178   971
    42 2007-07-18 14:36:39 2007-07-18 14:37:21       16   10    0   32   50   179   987
    43 2007-07-18 14:36:39 2007-07-18 14:37:20       16   10    0   32   50   180   981
    44 2007-07-18 14:36:40 2007-07-18 14:37:19       15    9    0   33   50   188   960
    45 2007-07-18 14:36:42 2007-07-18 14:37:21       14   10    0   37   50   222   990
    46 2007-07-18 14:36:42 2007-07-18 14:37:23       15    9    0   37   50   223 1003
    47 2007-07-18 14:36:42 2007-07-18 14:37:22       15   10    1   37   50   225   998
    48 2007-07-18 14:36:42 2007-07-18 14:37:23       14   10    0   37   50   226 1001
    49 2007-07-18 14:36:43 2007-07-18 14:37:19       14    9    0   40   50   237   961
    50 2007-07-18 14:36:43 2007-07-18 14:37:20       15    9    1   40   50   240   974
    51 2007-07-18 14:36:43 2007-07-18 14:37:20       13    8    0   40   50   241   972
    52 2007-07-18 14:36:44 2007-07-18 14:37:22       15   10    3   41   50   258   996
    53 2007-07-18 14:36:45 2007-07-18 14:37:19       13   10    0   44   50   268   958
    54 2007-07-18 14:36:45 2007-07-18 14:37:19       13   10    0   44   50   271   957
    55 2007-07-18 14:36:45 2007-07-18 14:37:20       13    9    0   44   50   272   969
    56 2007-07-18 14:36:45 2007-07-18 14:37:20       14   10    0   45   50   282   979
    57 2007-07-18 14:36:46 2007-07-18 14:37:21       13    8    0   47   50   290   985
    58 2007-07-18 14:36:46 2007-07-18 14:37:20       11    7    0   47   50   291   966
    59 2007-07-18 14:36:47 2007-07-18 14:37:21       13   10    0   49   50   303   986
    60 2007-07-18 14:36:47 2007-07-18 14:37:22       14   10    1   49   50   304   997
    61 2007-07-18 14:36:47 2007-07-18 14:37:19       12   10    0   50   50   316   950
Maximum size pool reached was 50
*** End of Report ***

Similar Messages

Regarding Thread Creation

Hello,
To create a thread in java there are two methods.
(1) by extending from thread class.
(2) by implementing runnable interface.
implementing runnable interface is the preferred method to create a thread because we still have the option to extend from any other class.
But does anybody know why java provides 2 methods for thread creation, why doesn't it provide only option 2 (i.e. by implementing runnable interface) when it is the preferred option.
Regards,
Sandy.

Though Runnable interface is preferred to create threads in Java,most programmers extends Thread class.As jschell would say, 'I am rather certain' that the opposite is true.
The reason behind of this is that you can have a clear logic of your code by using ThreadThat's not even true and it certainly isn't a reason to extend Thread rather than implement Runnable.
most of the system programming written in java used Thread class instead of Runnable interface .If you have some evidence on the point please produce it. The consensus of opinion on these forums has been the other way round for many years.

Thread creation error: Not enough storage is available to process this command

Two user in my company have this problem, I have already used the solution on the community but would come back after 2 to 3 weeks. They all have the message "Thread creation error: Not enough storage is available to process this command". I tried increase the virtual memory to 4Gb, update one client to the latest, reset IRPStackSize, delete temp folder. one client is 7.5.XX with windows 7 and another is 6.20.0.104 with Windows XP,My machine is also 6.20 with windows 7 but I dont have this problem.

Version previous to 7.6 worked fine. After update I have got this message and mostly of Skype GUI turns black or vanishes. No possibility of making more than one call before crash, It is amazing that a thread started about two weeks ago has no technical answer, at least. What do I do with my credits and my appointments? Throw them away?

Thread creation error: Not enough storage space

Hi,
Recently (the past week or so), my desktop client for Skype has been crashing regularly. This is accompanied by large (over 1.2GB) amounts of memory usage. At semi-regular intervals (say every few hours), Skype will post an error with the text "Thread creation error: Not enough storage space..."
I am using the latest build of Skype. I am not performing any Skype logging. This error is clearly an ongoing issue which has not been addressed, as prior threads have discussed this as well.

Errors like this have been addressed and continue to be addressed. Being that the errors are related to memory leakage of one form or the other, the problem can have several sources and be agitated by several programs. I personally run the latest version on all my machines in a 24/7 capacity and have not run into the problem. Some versions in the past created a similar error for me, yet the latest has not. If you've already updated your IE's flash and that has not alleviated the problem, the only other solution is running an earlier release that doesn't crash for you or restart Skype more often. I've had virtual video devices trigger this behavior by simply launching the video settings once. The virtual device even when not in use continued to consume memory under Skype until it crashed. So if you use any virtual audio/video components you may want to remove them to see if that changes anything. Some people have also blocked ads when those were the source.
http://community.skype.com/t5/Windows-desktop-client/low-storage/m-p/3974193/highlight/true#M344826

RoboCode crashes with SeedGenerator thread creation error?

Hello everyone.
I recently came across a game called RoboCode. It seems to be a tank battle simulator where you write the AI in Java.
Unfortunately, it won't start on my Windows computers. I get this error:
Exception in thread "SeedGenerator Thread" java.lang.InternalError: internal error: SeedGenerator thread creation error.
at sun.security.provider.SeedGenerator$ThreadedSeedGenerator.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)Anyone got any idea why? I haven't the foggiest clue how to fix it or get around it - or even what it means.
Thanks,
-Kramy

I'm awaiting a reply right now.
But if Google couldn't turn up much, then it probably isn't a very common error? ;)

Is the ThreadpoolExecutor thread safe?

Is the ThreadpoolExecutor thread safe? Is it safe to use a ThreadpoolExecutor from a multiple thread contexts?

If the API documentation says it's thread-safe, then it is. Otherwise you must assume it is not.

"Pause" Thread, thread creation & run performance

Hello,
I'm having an object executing tasks in response to events (I call it Executer)
In "normal" execution mode, it's executing 2 types of tasks: tasks1 and tasks2.
when a specific event occurs (pauseEvent), I want it to STOP executing tasks2 for a specific amount of time (in this example 100ms): I'm calling that a "pause"
it will still be executing tasks1 in the meantime, and will resume executing tasks2 only after the pause has expired.
to do so, when I receive a pauseEvent I create a new Thread (PauseThread) and start it.
it itself calls the "setPause(boolean p)" method of Executer to set the "pause" flag to true
then it waits for 100ms
then it sets back the pause flag to false
(Executer checks the pause flags before executing tasks2)
class PauseThread extends Thread {
    private TaskExecuter executer;
    private long                pauseTime;
    public PauseThread(Executer e, int t) {
        executer = e;
        pauseTime = t;
    public void run() {
        executer.setPause(true);
     try {
            sleep(pausetime);
        catch(InterruptedException e) {
            System.out.println("exception pause thread");
     executer.setPause(false);
}all is working fine.
however, I'm trying to improve performances.
the whole process of creating & starting the thread takes up to 50us, I want to reduce this as much as possible.
obviously, I create & start a thread every time I want to do a pause, I'm thinking there MUST be a way to avoid this, and simply call the setTrue / Sleep / setFalse part of the thread instead.
I was thinking about creating and starting the thread only once at the creation of my Executer, and calling the "pause()" method when needed:
class PauseThread extends Thread {
    private TaskExecuter executer;
    private long                pauseTime;
    public PauseThread(Executer e, int t) {
        executer = e;
        pauseTime = t;
    public void run() {
     while(true) {
    public void pause() {
        executer.setPause(true);
     try {
            sleep(pausetime);
        catch(InterruptedException e) {
            System.out.println("exception pause thread");
     executer.setPause(false);
}would that be correct ?
I'm concerned with the performance hit of the "while(true)" (as I'm fighting for micro-seconds, even the slighliest useless cpu hit should be avoided)
what if I had "sleep(1)" in my while loop ?
I'm pretty sure there's a better way to do this, any idea ? maybe using wait / notify, however I get the feeling those methods are not designed for this use...
any hint ?
thanks !

yes, I'm certainly reinventing the wheel ! but trying to understand it at the same time !
what was your other suggestion ? Timer + TimerTask ? I've already implemented it and using it now ! as I said it's working good, 3x improvement ! simply trying to see if there's a way to avoid creating a TimerTask object at each run.
coming back at the "piece of nonsense", what would this achieve:
class PauseThread extends Thread {
    private TaskExecuter executer;
    private long                pauseTime;
    private boolean           flag = false;
    public PauseThread(Executer e, int t) {
        executer = e;
        pauseTime = t;
    public void run() {
     while(true) {
            if(flag) {
                flag = false;
                sleep(pauseTime); // add try/catch
                executer.setPause(false);
    public void startPause() {
        flag = true
}then in my Executer, I create and start the PauseThread only once, and when I want to pause it, I simply do:
setPause(true);
pauseThread.startPause();in this case the sleep would execute in the run(), pause the "pause" thread, not the "executer" thread, no ?
I will read about the concurrency classes...

Callbacks without excessive thread creation and memory leaks?

Hi JNI experts,
I haven't done any serious JNI programming in a couple years and I'm currently stuck with a tricky JNI problem:
My JNI code is connected to a system driver and needs to do frequent callbacks into Java code. The standard way of doing this involves calling AttachCurrentThread and DetachCurrentThread before/after the callback to Java code. However, I noticed that AttachCurrentThread creates a new java.lang.Thread each time it is invoked. Let's just say that the callback is invoked from JNI very freqently, and creating a new Thread each time that happens is not acceptable behavior for my application. Among other things, it prevents me from using the Eclipse debugger because the large number of threads being created and destroyed effectively locks up Eclipse's debugger UI. Also, it creates a CPU load that is way higher than it should be for a light-weight operation.
So, I deviated from the standard Attach/DetachCurrentThread pattern and moved the DetachCurrentThread to code that is only called when the native JNI service is terminated. As that effectively renders repeated AttachCurrentThread calls a no-op, the problem of excessive creation and destruction of threads went away, but instead I had a memory leak on my hands now. The JNI code needs to create some Java objects because it's easier to create those objects right away rather than passing a bunch of primitives to Java and assembling them into objects there. When I moved the DetachCurrentThread, those newly created objects were no longer garbage-collected even after the Java code had released all references.
When you print the stack trace of the Java callback method there is always only one frame on the stack (since it is being invoked directly from JNI). However, I suspect that older stack frames from previous invocations keep hanging around somewhere else in memory if DetachCurrentThread is not called. In other words, moving DetachCurrentThread out of the callback is an even worse option. I tried using PopLocalFrame to get rid of left over stack frames, but that didn't seem to work.
So, my question is: is there a way to make (natively initiated) callbacks from JNI to Java without memory leaks and without creating a new thread each time? Would it work if I created my own native thread that runs some sort of dispatch loop? What other options are there?
Thanks for any ideas!

Thanks for the quick reply, ejp! :-)
Your comments were very helpful; let me clarify a few things:
I don't know where you get this 'standard Attach/DetachCurrentThread pattern', but if the native callbacks always happen on the same native thread, you only need to attach it once when you get the first callback, and detach it when you get the last, if you can tell. ;-)Yes, the callback is always coming from the same native thread, but, unfortunately, I cannot tell when I get the last callback, and essentially the native service keeps running as long as the VM is running. When I say "standard pattern" I'm referring to the fact that pretty much every book, tutorial, or web site that talks about JNI callbacks shows code snippets where AttachCurrentThread is called, then the callback, and then DetachCurrentThread.
The JNI code needs to create some Java objects because it's easier to create those objects right away rather than passing a bunch of primitives to Java and assembling them into objects there.Is it really? Are you sure?I'm pretty sure in this case, though your point is well taken. The native API that calls my JNI code produces packets of that contain about 15 pieces of information of different types (ints, longs, doubles). Several packets may arrive together in a single group. Handling the data on the Java side requires a Java callback method with 15 parameters for a single packet, and it's hard to reconstruct which packets belong to one group at that point. Creating corresponding Java objects in JNI and passing them inside an array to the callback function indeed turned out to be easier.
I don't think just 'moving' the DetachCurrentThread is correct. You need to attach the thread that is doing the callbacks, as often as necessary but no oftener, and detach it when you can.I think I found the solution: my native code is starting a separate dispatcher thread that, as you suggested, attaches itself only once and then enters a dispatcher loop. The low-level call back function notifies that thread of new data via the standard Pthread API. The detach happens in JNI_OnUnload. This works without creating a new thread each time and garbage-collects the created objects properly. As the dispatcher method essentially never returns I also had to insert some DeleteLocalRef calls, because otherwise the local references prevented garbage collection.
So, for now, it looks like I'm good to go. Thanks again for the reply!

Problem in thread creation

Hello Frnds,
i am learning j2me..i am facing some problem in simple thread initilization..
the code is
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
import java.io.*;
import javax.microedition.io.*;
class Process implements Runnable
private FileConnection MIDlet1;
private Display display;
public Process()
MIDlet1=MIDlet2;
public void run()
try
transmit ();
catch (Exception error)
System.err.println(error.toString());
public void start()
Thread thread = new Thread(this);
try
thread.start();
catch(Exception e)
// System.out.println(e);
private void transmit() throws IOException
try
OutputConnection connection = (OutputConnection)Connector.open("file://c:/myfile.txt;append=true", Connector.WRITE );
OutputStream out = connection.openOutputStream();
PrintStream output = new PrintStream( out );
output.println( "This is a test." );
out.close();
connection.close();
catch( ConnectionNotFoundException error )
catch( IOException error )
Alert alert = new Alert("Error", error.toString(), null, null);
alert.setTimeout(Alert.FOREVER);
alert.setType(AlertType.ERROR);
display.setCurrent(alert);
catch(Exception error)
public class FileConnection extends MIDlet implements CommandListener
private Command exit, start;
private Display display;
private Form form;
public FileConnection ()
display = Display.getDisplay(this);
exit = new Command("Exit", Command.EXIT, 1);
start = new Command("Start", Command.EXIT, 1);
form = new Form("Write To File");
form.addCommand(exit);
form.addCommand(start);
form.setCommandListener(this);
public void startApp() throws MIDletStateChangeException
display.setCurrent(form);
public void pauseApp()
public void destroyApp(boolean unconditional)
public void commandAction(Command command, Displayable displayable)
if (command == exit)
destroyApp(false);
notifyDestroyed();
else if (command == start)
process.start();
}//middlet ends here
this code is givin null pinter exception and it does not initialize proocess class..vat is error..plz let me know

oh ..there was some problem..sending it again
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
import java.io.*;
import javax.microedition.io.*;
public class FileConnection extends MIDlet implements CommandListener
private Command exit, start;
private Display display;
private Form form;
public FileConnection ()
display = Display.getDisplay(this);
exit = new Command("Exit", Command.EXIT, 1);
start = new Command("Start", Command.EXIT, 1);
form = new Form("Write To File");
form.addCommand(exit);
form.addCommand(start);
form.setCommandListener(this);
public void startApp() throws MIDletStateChangeException
display.setCurrent(form);
public void pauseApp()
public void destroyApp(boolean unconditional)
public void commandAction(Command command, Displayable displayable)
if (command == exit)
destroyApp(false);
notifyDestroyed();
else if (command == start)
Process process=new Process(this);
process.start();
}//middlet ends here
class Process implements Runnable
private FileConnection MIDlet;
private Display display;
public Process(FileConnection MIDlet)
this.MIDlet=MIDlet;
public void run()
try
OutputConnection connection = (OutputConnection)
Connector.open("file://D:/Programs/Hello.txt", Connector.WRITE );
OutputStream out = connection.openOutputStream();
PrintStream output = new PrintStream( out );
output.println( "This is a test." );
out.close();
connection.close();
Alert alert = new Alert("Completed", "Data Written", null, null);
alert.setTimeout(Alert.FOREVER);
alert.setType(AlertType.ERROR);
display.setCurrent(alert);
catch( ConnectionNotFoundException error )
Alert alert = new Alert("Error", "Cannot access file.", null, null);
alert.setTimeout(Alert.FOREVER);
alert.setType(AlertType.ERROR);
display.setCurrent(alert);
catch( IOException error )
Alert alert = new Alert("Error", error.toString(), null, null);
alert.setTimeout(Alert.FOREVER);
alert.setType(AlertType.ERROR);
display.setCurrent(alert);
catch(Exception e)
System.out.println(e);
public void start()
Thread thread = new Thread(this);
try
thread.start();
catch(Exception e)
System.out.println(e);
}

ThreadPoolExecutor- Thread termination

I created a thread pool executor and submitted some callable tasks to thread pool and waiting on future object in the method futureobject.get(timeout, TimeUnit.SECONDS).
Once it is timed out i am catching the TimeoutException and cancelling the task through future.cancel(ture),
But it is just interrupting the thread and not cancelling the task if the task has already started executing.
Is there any way to stop the future Object task after a certain time out irrespective of its current state?
I want to terminate the thread execution and make the thread pick another task once if it is timed out.
One way is to interrupt the thread which is handling the future object task and then stop the thread.
Is there any other way that I can cancel a future Object task directly without dealing with the thread handling this future object task.
Can you throw a light on this. Any idea would be helpful...!!
Thanks in advance.

Thanks Peter for your reply.
But the problem is the thread is not like executing in a while loop to test every time whether it is interrupted or not by future.cancel(ture).
As my callable task is calling internally more methods which are call some more methods of other classes in this i cant put every where this logic to check whether thread is interrupted or not.
Even i have done that my concern is what if thread is executing a method long time because of some blocking problem. i need to wait the control comes back after method to check whether thread is interrupted or not. which is not desired..
let me put in an example.
public Object call(){
new ArrayList list=SampleClass1Object.readData();
// check whether thread is interrupt by future.cancel() method
Object ob= SampleClass2Object.display(list);
return ob;
If i fix time in future.get(timeout,TimeUnit). when the time out is happend the thread executing the method readData() it wont reflect immediately once this readData() method is completed then only it will check whether the thread is interrupted or not. This what is happening right now in my case.

Off topic but, Mods, i cannot reply to a thread I made

I posted a thread here earlier about wav files being blank. Someone replied yet I am not able to reply to my own thread, there is no link to do so. i tried logging in and out and nothing. Just wanted to let you know and this has happeend many times already actually.

After you log out, make sure to clean out your browser's cache completely, not just the history and not just the cookies. Get rid of site preferences and and session data as well. The free app CCleaner works well for that if doing it in your browser isn't enough.
Jeff

Dynamic Thread Creation

To anyone that can help,
I am very new to JAVA, and have been given the job of creating an application that allows a user to dynamically create a number of process which perform the same task (its a load-testing tool). I thought that using threads would be the best approach, however, I am not sure how to instantiate them dynamically. The two ways I known are :
1.
NewThread one = new NewThread(arguements);
one.start();
2. new NewThread(arguements).start();
The second one would probably work via. user input. The problem is that since I haven't named the object (like in case 1) I can't access its methods (i.e. join()). I guess this question could be extend to consider creating any object dynamically, so any help would be very much appreciated.
Thanks

I'm not entirely sure of what your question is... but I'll try to guess at it.
The only difference between the two approaches is whether your program will keep a handle/reference to the class that extends Thread or implements runnable.
NewThread one = new NewThread(arguements);
one.start(); In the first case you can just take your "one" variable and throw it into a container, if you want to reference it and others like it.
2. new NewThread(arguements).start(); In this case, you don't have a variable that references the thread that you just started.
Can you provide more information on what you want to do with the Thread process once it has started?
Thanks,
Tim
To anyone that can help,
I am very new to JAVA, and have been
and have been given the job of creating an application
that allows a user to dynamically create a number of
process which perform the same task (its a
load-testing tool). I thought that using threads would
be the best approach, however, I am not sure how to
instantiate them dynamically. The two ways I known are
1.
NewThread one = new NewThread(arguements);
one.start();
2. new NewThread(arguements).start();
The second one would probably work via. user input.
The problem is that since I haven't named the object
(like in case 1) I can't access its methods (i.e.
join()). I guess this question could be extend to
consider creating any object dynamically, so any help
would be very much appreciated.
Thanks

Thread creation in c++

Hi, all !
I am working on a c++ program. I have created a class called threads abnd now I want to know whether there is a function for creating threads.I am new to solaris.I don't have a idea about what function to use to create threads in c++.
I also want to know whether there is a function to synchronize the created threads while they are accessing a shared memory. Thankyou very much.
Vij.

Please do not post the same question more than once. See my answer here:
http://forum.java.sun.com/thread.jspa?threadID=5128430

Thread creation questions

I'm creating a diary type program (dates and times of various things) and am having a few problems creating threads. I'm understanding how to create the threads I think, but from what I've been able to understand, everything that the tread runs is in the run() method only. So how do I make it run other things?
for instance, I have a search method which searches through a load of objects (the tasks). Can I run this search method in its own thread?
Thanks
Adrian

agehoops wrote:
Well I plan to put a GUI on the top of it so obviously that'll have its own thread but I don't want anything to lock up while it's searching through potentially hundreds of objectsThat's a little better. If you are using Swing and Java 6, have a look at using a SwingWorker object. It smooths over some of the difficulties of doing Threading with Swing. There's a decent tutorial on using this here:
[Lesson: Concurrency in Swing|http://java.sun.com/docs/books/tutorial/uiswing/concurrency/index.html]

Automatic thread creation?

Hi,
While linking a 3rd party library I noticed that my single threaded program was being recognized as multi-threaded by workshop & also the executable had 4 threads running. After some investigation, I realized that this was due to the library having a dependency on pthreads. I was able to duplicate this by writing a c program and linking with either pthreads or threads.
foo.c:
main ()
while (1)
Compiling & linking this with :
cc foo.c -lthread
& executing this :
a.out &
Now the "ps -L" command displays 3 threads with only one of the threads running. My question is whether this is normal or can I set any compiler flags/apply any patches to change this behaviour?
My development environment is Solaris 8 with Forte 6.2
Thanks,

The four threads your seeing are :
The primary thread (The one you expect)
A ASLWP thread to handle signals
A reaper thread to clean up detached threads
An lwp that deals with the kernel
This is due the the MxN thread model type that Solaris 8 and
lower has.
If you use Solaris 9 or use the threads library at /usr/lwp/libthread
instead of /usr/lib/libthread on Solaris 8, (set your
LD_LIBRARY_PATH), you will just see the primary thread.
This is because a one-to-one threading model is used here.
Solaris 8 actually shipped both thread models.

ThreadPoolExecutor - thread creation madness

Similar Messages

Maybe you are looking for