Multi-threaded programming.

[Martin]

I've been playing around with Java threads, and as cool as they are, I really have no idea when I should (or shouldn't, for that matter) use them.

Does anyone know of any good resources on the theory behind multi-threaded programming?

Thanks in advance.

[rizzix]

No no resources. But they come of great use when programming GUI. Threads can make the perceived performance appear a lot faster than what it would look like without them. Hence they are crucial in GUI programming.

I guess the other time you would use threads is when you have an algorithm that can take advantage of two CPU's (Of course this largely depends on the underlying OS, but it's best to plan for the greatest advantage). Aside that, I haven't found a reason to use them yet.

Edit: Oh and the other time they are of great use is in networking. Specifically client-server networking.

[Hikaru79]

I had to sort of dive in headfirst with Threads when doing my final project last year (a client-server pair for playing Shogi). Each session, of course, needed its own Thread (or two). It all went rather well except for a dirty little hack wtd suggested where I had to connect to my own ServerSocket's in order to stop the thread waiting for I/O when I wanted it to terminate. I'm still not sure if there's a more elegant way of doing that.

I still have the source for it, if you want to take a look. I'm not claiming to be at all competent in multi-threaded programming, but I *did* write a large-ish program that made very extensive use of threads without having any thread-related bugs in it that I could find. Let me know.

EDIT: Oh yeah, forgot to mention. This was in Java.

[rizzix]

Consider this example Hikaru. I hope it helps..

Java:

class Test extends Thread {     private boolean cont = true;         synchronized public void stopExec() {         cont = false;     }         synchronized boolean cont() {         return cont;     }     public void run() {         try {             while (this.cont()) {                 System.out.println("bla");                 Thread.sleep(500);             }         } catch (Exception e) {             System.out.println(e);         }     }         public static void main(String[] args) {         Test t = new Test();                 System.out.println("starting thread");         t.start();         try {             Thread.sleep(5000);             System.out.println("stopping thread");             t.stopExec();             System.out.println("thread stopped");         } catch (Exception e) {             System.out.println(e);         }     } }

where Thread.sleep is replaced with appropriate wait() calls.

[Hikaru79]

rizzix wrote:

Consider this example Hikaru. I hope it helps..

Hm? Why me? Or did you mean Martin...?

[rizzix]

No, you. That's the more elegant way of stopping a thread? =/

[Hikaru79]

rizzix wrote:

No, you. That's the more elegant way of stopping a thread? =/

Yes, but the problem is, all my thread did was wait for input across the network. Now, Thread.stop() is deprecated, and I can't just put the run() in a loop, because the execution waits on the socket.readLine(); until it gets some input. However, if that input isn't coming, it'll just hang there forever unless you force some input in. Is there any way to get around this I/O lock threads seem to experience?

[md]

Hikaru79 wrote:

rizzix wrote:

No, you. That's the more elegant way of stopping a thread? =/

Yes, but the problem is, all my thread did was wait for input across the network. Now, Thread.stop() is deprecated, and I can't just put the run() in a loop, because the execution waits on the socket.readLine(); until it gets some input. However, if that input isn't coming, it'll just hang there forever unless you force some input in. Is there any way to get around this I/O lock threads seem to experience?

Asyncronous sockets. If there is data waiting to be read, read it; otherwise skip the read step (optionally delay instead) and loop again. If you opt for the delay you can make it less of a busy wait. Dynamically modifying the delay length based upon when you last got data also helps keep busy waiting to a minimum.

[rizzix]

Hikaru, mind posting just your run() method here?

[Hikaru79]

Cornflake wrote:

Asyncronous sockets. If there is data waiting to be read, read it; otherwise skip the read step (optionally delay instead) and loop again. If you opt for the delay you can make it less of a busy wait. Dynamically modifying the delay length based upon when you last got data also helps keep busy waiting to a minimum.

Wow! That is exactly the sort of thing I was asking on #java about a year ago, but they assured me no such mechanism existed. Shows what they know. Can you link me to any sort of implementation of this, Cornflake?

Rizzix, sure. But keep in mind that I had a seperate ClientLayerListener class that was a thread (owned by each Session thread) that would do nothing but get input, relay it to its parent Session, then go back to listening. So here's the run(), basically. It's nothing fancy:

Java:

public void run(){             while (listening){             delegateInput(recieveInput());             }         }

And here's the "recieveInput()" method it talks about there:

Java:

public String recieveInput(){             String inputLine = "error 03";                 try{                 inputLine = in.readLine();                 }                 catch (IOException f){                  listening = false;                  throw f;                 }             finally{ return inputLine; }         }

(Where 'in' is the Socket's input stream)

So 'listening' was an instance variable. If I set it to 'false', it would stop the thread, but only after it got to the end of the loop. If it was still on line "delegateInput(recieveInput());", then it wouldn't stop executing until it got past that line. What I did was just connect to it myself. It worked, but not prettily.

I'm interested in what Cornflake talked about. Linkage, please?

[bugzpodder]

http://www.topcoder.com/longcontest/?module=Static&d1=intel_overview

[Martin]

How many threads can a program safely handle, assuming the programmer knows what they're doing?

[zylum]

http://www.topcoder.com/tc?module=Static&d1=tutorials&d2=wavefrontPattern

pretty interesting

[md]

Martin wrote:

How many threads can a program safely handle, assuming the programmer knows what they're doing?

In Java specifically I don't know if there is a limit or not, usually though the limit is based on the operating system. So long as all the threads aren't writing to the same varaible then really there's nothing keeping you from running as many as you like.