 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / September 2007simultaneous function calls
Hi All, I have not much experience with programming threads and competeing processes. I have an application, where several threaded-objects (each with an own thread), are using the methods of a single (non-threaded) object. I have no influence on the call frequency of theese threaded objects, so it can easily happen, that 2 calls arrive at the same time, or a call arrives when the object is still not returned from the previous call. I have experienced, that the application works the more erroneously the more such "threaded instances" I have (with only one it works perfectly, but I need in the final app around 15 of them!) My question is: How java handles such calls. Is there some FCFS Queue, so that each request is going to be satisfied sooner or later, or there can be such requests, which can be forgotten? Best, korcs korcs schrieb: > Hi All, > [quoted text clipped - 7 lines] > call arrives when the object is still not returned from the previous > call. 2 calls at the same time should not be a problem, if you synchronize the method using the "single (non-threaded) object" as monitor. Simply add "synchronized" as keyword to the called method. > I have experienced, that the application works the more erroneously > the more such "threaded instances" I have (with only one it works > perfectly, but I need in the final app around 15 of them!) This could be a synchronizing problem. But it's difficult to tell without source code. > My question is: How java handles such calls. Is there some FCFS Queue, > so that each request is going to be satisfied sooner or later, or > there can be such requests, which can be forgotten? "sooner or later". This is controlled by the operating system (so, threads have not the same scheduler on windows and linux for example. To give the Threads a higher priority, use the threads "setPriority()" method. > Best, > > korcs korcs schrieb: >> I have an application, where several threaded-objects (each with an >> own thread), are using the methods of a single (non-threaded) object. > 2 calls at the same time should not be a problem, if you synchronize the > method > using the "single (non-threaded) object" as monitor. There is no such thing as a "non-threaded" object. Since the object in question is used by many threads simultaneously, any association with it of the term "non-threaded" is erroneous in this case. The object must be written to be thread-safe. > This could be a synchronizing problem. But it's difficult to tell > without source code. It's easy to tell without the source code: it's a synchronization problem. > To give the Threads a higher priority, use the threads "setPriority()" > method. Not reliable, and not the answer to the OP's real problem. <http://tns-www.lcs.mit.edu/manuals/java-tutorial/java/threads/priority.html> > Rule of thumb: At any given time, the highest priority thread is running. However, this is not guaranteed. The thread scheduler may choose to run a lower priority thread to avoid starvation. For this reason, use priority only to affect scheduling policy for efficiency purposes. > Do not rely on thread priority for algorithm correctness. The tutorial that Sabine recommended is a necessary beginning. Study /Java Concurrency in Practice/ by Brian Goetz, et al., for more mastery. Thread programming is a subtle and dangerous art.  SignatureLew > Hi All, > [quoted text clipped - 19 lines] > > korcs There's a very good lesson in Suns tutorial: http://java.sun.com/docs/books/tutorial/essential/concurrency/ SignatureSabine Dinis Blochberger Op3racional www.op3racional.eu >My question is: How java handles such calls. Is there some FCFS Queue, >so that each request is going to be satisfied sooner or later, or >there can be such requests, which can be forgotten? I implemented a simple thread system in C circa 1992. It kept a control block for each thread. Each thread ran until it called "haveAConscience". The thread manager stored its registers and stack away for safekeeping. (Most of the stack was already in RAM). At that point the thread manager picked the highest priority thread ready to run, (which might be the same thread), restored its registers and stack, and resumed it. It was based on experience with the co-operating multitasker I had used in the Univac 1616 military mini (for peaceful purposes as a datacommunications front end to a mainframe) in the early 70s. Java is more sophisticated. Threads don't have to call "haveAConscience" periodically. There is a hardware timer in the OS that goes off at the end of a slice. It can put a thread to bed in the middle of evaluating an expression, or sometimes even in the middle of an instruction. Threads ask to be put to sleep when they do I/O and wake up, getting on the active queue when the I/O completes. The OS, not Java handles most of this. A Thread in Java is the set of machine registers, and the contents of a stack (locals, return values to callers, parameters). My current machine has two CPU cores, so it can run two threads fully simultaneously. Cheaper hyperthreaded machines simulate dual or more CPU cores, so the threads interleave on a cycle by cycle bases, rather than timeslice by timeslice. see http://mindprod.com/jgloss/thread.html SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com Thanks for your replies! I found myself a really good tutorial for java threads as well. http://www.freejavaguide.com/java-threads-tutorial.pdf While reading your comments and the suggested tutorials, I was wondering whether my problem was really a synchronization problem. Maybe I did not understand everything quite well, but it seems to me, that synchronization is needed in situations where 2 or more threads could WRITE(!) global variables simultaneously and make data inconsistent. So it means that if a method, used maybe simultaneously by multiple threads causes only a READ action on program data, then synchronization is not necessary (not needed and would cause only an unneccesary overhead). Is it correct or did I miss something? Best, korcs > Maybe I did not understand everything quite well, but it seems to me, > that synchronization is needed in situations where 2 or more threads [quoted text clipped - 5 lines] > synchronization is not necessary (not needed and would cause only an > unneccesary overhead). Not really. Imagine your method is traversing a file. Then every call to it moves the file pointer, and gives you unexpected results. Maybe you could describe your *specific* situation better, with some code, then people could find the culprit. SignatureSabine Dinis Blochberger Op3racional www.op3racional.eu > Thanks for your replies! > [quoted text clipped - 14 lines] > synchronization is not necessary (not needed and would cause only an > unneccesary overhead). False if the datum in question is non-immutable and non-final. > Is it correct or did I miss something? You missed something. If more than one thread /accesses/ a variable, read or write, you must synchronize. The "synchronized" keyword is not the only way to synchronize. Compile-time constants and static final immutable objects are synchronized by the rules of when such things are created. Thus read-only access can avoid "synchronized" in such cases, but it doesn't avoid synchronization. SignatureLew Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.