Thanks a lot for all answers. It is exactly what my doubts were, and thanks for the "long" related info.
Gabriel Roldán [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Java and GIS Project Leader Dominion t.i. www.dominion.es www.bizkaia.net -----Mensaje original----- De: Pillai Jaideep, App Spec, SCS-SD [mailto:[EMAIL PROTECTED]] Enviado el: miércoles, 19 de febrero de 2003 11:06 Para: [EMAIL PROTECTED] Asunto: Re: stupid question Raul, I take it that your question is whether static methods are explicitly synchronized by the JVM? The answer is, NO, they are not. No harm if the static method does not use any global static variable within the class, every thread entering the method would get its own stack for execution of the method. But, be especially wary of the situation where the static method does use some global static variable declared within the class. If the method block is not synchronized, it will result in simultaneous modification of the variable by the entering threads, thus resulting in nasty destruction of data held by that variable. Funny , but I'll mention this. All Java primitive data types are thread safe( means two Java threads cannot simultaneously modify the value of the data held by the variable). But recently I found that the "long" primitive is not thread safe. This is because the JVM holds a long(64 bits) in 2 32-bit registers. Hence, it is possible that while one thread is modifying the value of one of these registers, another one might simultaneously modify the other register. Do not be too confident of your "long"s, if you do have a method manipulating a global long in a multi-threaded environment, remember to synchronize the method. Jaideep. -----Original Message----- From: ROLDAN, Gabriel raul [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 18, 2003 9:01 PM To: [EMAIL PROTECTED] Subject: Re: stupid question I mean in general, beans for example. the source of this question is my confussion about the internals of reentrant functions and synchronization -----Mensaje original----- De: Amit Ghaste [mailto:[EMAIL PROTECTED]] Enviado el: sábado, 15 de marzo de 2003 12:32 Para: [EMAIL PROTECTED] Asunto: Re: stupid question vikramjit, I think he meant it in relevance to JSP. correct me if I am wrong Roldan, but did u mean declaring static variables and/or static methods declared in a jsp page... if so no, you will need to implement synchronization... consider performance and benefits of the approach as well. -----Original Message----- From: A mailing list about Java Server Pages specification and reference [mailto:[EMAIL PROTECTED]]On Behalf Of Vikramjit Singh Sent: Tuesday, February 18, 2003 12:13 AM To: [EMAIL PROTECTED] Subject: Re: stupid question Rather this is a very interesting question but not related to jsp specifically. In one simple word the answer is yes you can lock a static variable. First, any member variable that you wish to make thread safe must be declared private. Consider the following code: public class MyPoint { public int x; public int y; public int getX() { return x; } public int getY() { return y; } public synchronized setX(int x) { this.x = x; } public synchronized getY(int y) { this.y = y; } } If this were an ideal world, everyone would set x and y by calling setX() and setY(), respectively. However, we all know that someone will come along and set x or y directly, since we defined the members as public. And since we defined x and y as public, it is reasonable for someone to come along and access the variables directly. If we didn't want someone to access the members directly, we shouldn't have declared them as public in the first place! The only way to guarantee that threads will access x and y safely is to declare them as private and provide synchronized access. Nothing changes when you declare a member static. If you don't want some thread to come along and bypass your careful synchronization, don't declare the member public or protected. Now, the question remains: how do we lock the member? Sometimes I think that part of the confusion around synchronization stems from a misunderstanding of what actually happens when you call synchronized(some_object). Calling synchronized on some_object does not prevent access to some_object. Instead, you must think of synchronized as a request to open a lock around some piece of code for your thread. some_object is the lock that you wish to have access to. Only one thread may hold a specific lock at any one time. Making a static member thread safe is fairly simple once you understand what really happens when you call synchronized. Here is a template to follow (there are many more ways to do it, though): class Safe { ... other class definitions ... private static <type> var; public final synchronized static setVar(<type> val) { var = val; } } As a second option, you can also synchronize within the method. Which approach you take will depend upon your code. However, in this example, either way is equivalent, since a synchronized static method grabs the lock on the class. You would use the second option if you were doing a lot of processing inside of the method. That way you only synchronize when you have to -- thus improving performance. You would need to use synchronization within the method if you didn't want to declare setVar() static. A nonstatic method declared as synchronized locks on the instance, not the class. So, if you had more than one instance, the member would no longer be thread safe. -----Original Message----- From: A mailing list about Java Server Pages specification and reference [mailto:[EMAIL PROTECTED]]On Behalf Of ROLDAN, Gabriel raul Sent: Monday, February 17, 2003 6:59 PM To: [EMAIL PROTECTED] Subject: stupid question excuse this stupid and out of topic question, but.. ¿are static methods and fields synchronized? ========================= To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com =========================================================================== To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com =========================================================================== To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com ==========================================================================To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com ==========================================================================To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com ==========================================================================To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant archives, FAQs and Forums on JSPs can be found at: http://java.sun.com/products/jsp http://archives.java.sun.com/jsp-interest.html http://forums.java.sun.com http://www.jspinsider.com
