On 7-May-2009, at 19:05, David Kerber wrote:
Andre-John Mas wrote:That would be my impression too. It is best to avoid making the synchronized scope so large, unless there is a very good reason.David, do you have any reason for this? Beyond the counter, what other stuff do you synchronise? Also, it has generally been recommended to me to avoid hitting the disk in every request, since you may result with an I/O bottle neck, so if you can write the logs in batches you will have better performance. If you know that you are only going to have very few users at a time (say, less than 10), it may not be worth the time optimising this, but if you know that you are going to get at least several hundred, then this is something to watch out for.Thanks for the comments, Andre-John and Peter. When I wrote that app, Ididn't know as much as I do now, but I'm still not very knowledgeable about synchronized operations.The synchronized section doesn't do a whole lot, so it doesn't take longto process. My question is, what kinds of operations need to besynchronized? All I do is decrypt the data from the POST, send a small acknowledgement response back to the site, and write the line to the logfile. Does that sound like something that would need to be synchronized? If not, pulling that out would be a really easy test to see if it helps my performance issue.
I am no expert in this myself, but I know enough to help me out in most day to day scenarios. What you should be reading up on is concurrency in Java. A few useful resources:
site: http://java.sun.com/docs/books/tutorial/essential/concurrency/ book: http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601 I actually bought the book myself and find it a handy reference.What I can say is that any time two threads are likely to access the same object, which has the potential to be modified by one of them, then you will need to synchronize access to the object. If the object is only going to be read during the life of the "unit of work", then you will need not synchronize it. You shouldn't simply use the synchronize keyword as a magical "solve all" for threading issues and instead need to understand what the nature of the interactions are between the threads, if any. In certain cases it is actually better to duplicate the necessary resources, have each thread work on its copy and then synchronize the value at the end.
In the case of your code, you should ask what are the shared objects that are going to modified by the threads. You should also look if it is even necessary for the objects to be shared. Also consider whether for the call cycle the objects you are going to modify are only available on the stack, as opposed to a class or instance member.
To give you a real world analogy: consider a home that is being built and you have an electrician and a plumber: - is it better to have one wait until the other is finished (serial execution)? - is it possible for them to be working on different stuff and not be stepping on each other's feet? (parallel execution) - if you need them to work at the same time, what is the cost of coordinating each other so that
they do not interfere with the other? (synchronization issues)
In many ways multi-threading is not much different, and you should be
asking yourself the same type of questions.
André-John --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
