Head First Java - Sockets and Threading Chapter
This is a great chapter for a quick overview of the basic concepts of sockets and threading. It would be nice if it was just a plain threading chapter, but the socket example helps explain the concept of the blocking state really well. Suggest downloading the code and running the examples.
471 - we will create a multithreaded chat client to illustrate threading
472 - pic of chat client app, ignore beat box picture
473 - clients request connection to a server on port x
474 - client connects, sends a message to server, and server sends response back to everybody (including client that sent)
475 - clinet needs ip and port of server
476 - ports identify programs on a server, less 1024 reserved by sysadmin
477 - only one program per port (else bind exception)
478 - to read client creates socket to server, and wraps that in an inputstreamreader, we put that in a buffered reader to get input
479 - to write client uses same socket, and puts it into a printwriter, then writer.print("hi");
480 - the daily advice program explained
481 - daily advice code, see sample code
482 -
483 - simple server has two socets one for accepting clients, one for writing to
484 - the code
485 -
486 - chat client
487 -
488 - client can poll every 20 seconds, pull on sending chat, or listen for messages with multithreading
489 - multi threading in java splits up cpu
490 - Thread class is not a thread of execution (like a frame in a call stack)
490 - x
491 - Give a Thread class something that implements Runnable, and start it
492 - x
493 -
494 - good time to run the socket example, if you were to debug the program you'd notice the server flat out stops executing code on the serverSock.accept method. It's currently "blocked"
495 -
496 - a thread can go from "Runnable" to "Running", or "Running" to "Blocked"
497 - thread schedulers run different on all jvms (no guarentes, you can use make it go from "Running" to "Sleeping" to force an exit for a certain amount of time
498 - examples to illustrate thread scheduler inconsistency
499 - x
500 - some people extend thread and not runnable, that's hacky. also once a thread exits run(), it's in "Dead" state and can't be restarted (threads in thread pools never go to the dead state)
501 - rare api call that can wake a sleeping thread, so now everybody has to catch the thread interrupted expecetion on a sleep(n) call
502 - example using sleep to make thread scehduling more consistent
503 - example of running two threads at once this is concurrency
504 - concurency can lead to race conditions, two objects operating on the same data unaware of the others messing with data
505 - ryan checks bank account and sees 0, before withdrawing he falls asleep, Monica check bank account and see 0 and widthdraws , ryan wakes back up and continues his transaction of 50, now account is at -25$
506 - ryan monica in code
507 - ryan monica in code
508 - output showing overwidthdraw
509 - let's put a lock and key on ryan and monicas account
510 - atomic: it must be allowed to finish, use synconrized to put that lock on a piece of code and make it atomic
511 - each object has one key, even if it has multi synconrized methods. it's like 1 lock protects all the data on that object. thread grabs key wont give it up until syncronized block is done
512 - lost update problem, two threads operatin on this code may loose updates if one pauses between getting and incrementing
int i = balance;
balance = i + 1;
513 - explain thread states in lost balance example
514 - just syncronize that code to fix, don't sync everything because its slow, matter of fact, just sync the code that can lead to issues
515 - story of threads waiting for sync
516 - deadlock is two threads waiting for each others key, thread a gets key of foo, thread B get key of bar, a tries to get key of bar, b tries to get key of foo (deadlock)
517 - summary
518 - simple chat client with thread code
519 - code for runable that listens for chat data
520 - full chat client code
521 - more code
522 - the Dog objects means four locks, one for static class. threads have priority settings but no guarantee on order (this is for performance). syncing getters and setters seems like a way to stop threading issues, but the real issue is the way the threads use those getters and setters