Is System.arraycopy thread safe?

I found many IO Servers use this method to perform underlying data copy, but it is really safe to use it in such environment?
please help!

what do you mean by, 'would it help'? Help thread safety? No. The method returns quicker because it is native, but it does not impact thread safety (unless you consider a quicker return to some how increase thread safety).

Similar Messages

List of Non-thread safe system calls in Solaris 2.6??

Hi,
I'm searching for a list of system calls which are known to be non thread safe in a multithreaded process in Solaris 2.6. Anyone know of such a list?

I'm not aware of any list but you can easily find the list by looking for the following pattern in the man pages :-)
| ATTRIBUTE TYPE| ATTRIBUTE VALUE|
|__________________________________
| MT-Level | Unsafe |
|_______________|_________________|
HTH
Angelo
Sun Developer Support.

Non-thread safe System.console(), although synchronized used?

Hi, I recently noticed that the System.console() code looks like the following:
public static Console console() {
         if (cons == null) {
             synchronized (System.class) {
                 cons = sun.misc.SharedSecrets.getJavaIOAccess().console();
         return cons;
     }Is this thread safe, despite the synchronized block? I mean, suppose two threads try to get the console, and they both go past the null check. Then, one of them gets the lock, initializes the field blah blah. Then, the second gets the chance to run, and since it is past the null check, it will enter the synchronized code again. I don't know what happens in the sun.misc package, but as far as this code is concerned, this doesn't look valid to me. I might be wrong though :-)
Cheers.

DeltaGeek wrote:
Correct, that is not thread-safe. Why not just make the entire method synchronized?Because if cons is already non-null, there's no need to synchronize (assuming cons is the same object for each thread, something not evident in the code snippet...)
I'd put forth this:
public static Console console() {
         if ( null == cons ) {
             synchronized (System.class) {
                 // need second check in case cons was set while the thread
                 // was blocked
                 if ( null == cons ) {
                     cons = sun.misc.SharedSecrets.getJavaIOAccess().console();
         return cons;
     }And yes, I always put the non-L-value first, just in case I make a typo like this:
int x;
if ( x |= SOME_CONSTANT ) ...

Using System.arraycopy to copy an array into itself.

I was wondering if there are any potential problems with using code similar to below?
System.arraycopy(Global.queueUrgent, 1, Global.queueUrgent, 0, Global.queueUrgent.length-1); I have an array which works as a job queue. Another thread looks at this queue and then acts on it according to the data held in Global.queueUrgent[0]. Once this task has been accomplished, the first job is removed and the rest of the queue is brought forward one (and hence the code sample).
I understand the risks of a race condition which might occur in my application and can prevent it as much as possible but I was wondering if there were any other concerns I should address. It's important that I use an array such as this for my project.
I haven't tried to implement the code as of yet as I would like to hear your thoughts on it first.
Regards,
Robert (1BillionHex).

user13702320 wrote:
"If the src and dest arguments refer to the same array object, then the copying is performed as if the components at positions srcPos through srcPos+length-1 were first copied to a temporary array with length components and then the contents of the temporary array were copied into positions destPos through destPos+length-1 of the destination array. "
Yeah I understand that. I was just wondering if there was anything that I was missing.
It says "as if" it is copied to a temporary array. Does it actually do this? If so and if I use a large array, would this have an impact on memory usage?It doesn't matter if it actually does it using a temporary array. The point is, it is safe to use the same array for src and dest. Note that java.util.ArrayList's 'remove' method uses exactly the code that you are using. I don't know about memory usage effects. If you do this manually, you do need to set Global.queueUrgent[Global.queueUrgent.length-1] to null to ensure that the objects will be able to be garbage-collected properly when it is time (see what ArrayList.remove does). If you don't, then if you had a 5-element array and remove all 5 elements, you will end up with 5 references to what was originally only in queueUrgent[4], and the object won't be eligible for garbage-collection.
I did have the same question as Kayaman--why not use a real queue? There are several built-in classes that you can use, instead of using an array directly. You claimed that "It's important that I use an array such as this for my project.", but you didn't explain why you think you must use an array.

Is ArrayList(Collection c) constructor Thread-Safe?

Hi,
Say I have the following statement
public List getList() {
        return new ArrayList(myList);
}Assuming I also have other methods which use/modify myList, does this method above need to be synchronized?
Looking into the ArrayList contructor, this eventually calls a static native method System.arraycopy, is this implicitly synchronized as it is native or do I need to take care of this myself?
Thanks

The constructor new ArrayList(List) is thread safe because no other thread can access the ArrayList until it because visable to another thread.
The myList might not be thread safe. i.e. is possible you could be copying the myList while another thread is modifying it? If so then myList should be synchronized.
Using Vector makes no difference as the list with an issue is myList. Even if myList was a Vector you would have same problem as more than one method is accessed so you would have race condition.
   public ArrayList(Collection c) throws NullPointerException {
        size = c.size();
        // Allow 10% room for growth
        elementData = new Object[
                (int) Math.min((size * 110L) / 100, Integer.MAX_VALUE)];
        c.toArray(elementData);
    }Note: the c.size() can change between c.size() and c.toArray() being called or while c.toArray() is called. The race condition could mean the collection not being copies or an exception being thrown even if all the methods on the collection are synchronized.
If you think Vector is so different.
    public Vector(Collection c) throws NullPointerException {
        elementCount = c.size();
        // 10% for growth
        elementData = new Object[
                (int) Math.min((elementCount * 110L) / 100, Integer.MAX_VALUE)];
        c.toArray(elementData);
    }The only real solution is if myList can be modifed by another thread is to synchronize it and add the following.
public List getList() {
   synchronized(myList) {
         return new ArrayList(myList);
}

SSRS - Is there a multi thread safe way of displaying information from a DataSet in a Report Header?

In order to dynamically display data in the Report Header based in the current record of the Dataset, we started using Shared Variables, we initially used ReportItems!SomeTextbox.Value, but we noticed that when SomeTextbox was not rendered in the body
(usually because a comment section grow to occupy most of the page if not more than one page), then the ReportItem printed a blank/null value.
So, a method was defined in the Code section of the report that would set the value to the shared variable:
public shared Params as String
public shared Function SetValues(Param as String ) as String
Params = Param
Return Params
End Function
Which would be called in the detail section of the tablix, then in the header a textbox would hold the following expression:
=Code.Params
This worked beautifully since, it now didn't mattered that the body section didn't had the SetValues call, the variable persited and the Header displayed the correct value. Our problem now is that when the report is being called in different threads with
different data, the variable being shared/static gets modified by all the reports being run at the same time.
So far I've tried several things:
- The variables need to be shared, otherwise the value set in the Body can't be seen by the header.
- Using Hashtables behaves exactly like the ReportItem option.
- Using a C# DLL with non static variables to take care of this, didn't work because apparently when the DLL is being called by the Body generates a different instance of the DLL than when it's called from the header.
So is there a way to deal with this issue in a multi thread safe way?
Thanks in advance!

Hi Angel,
Per my understanding that you want to dynamic display the group data in the report header, you have set page break based on the group, so when click to the next page, the report hearder will change according to the value in the group, when you are using
the shared variables you got the multiple thread safe problem, right?
I have tested on my local environment and can reproduce the issue, according to the multiple safe problem the better way is to use the harshtable behaves in the custom code, you have mentioned that you have tryied touse the harshtable but finally got
the same result as using the ReportItem!TextBox.Value, the problem can be cuased by the logic of the code that not works fine.
Please reference to the custom code below which works fine and can get all the expect value display on every page:
Shared ht As System.Collections.Hashtable = New System.Collections.Hashtable
Public Function SetGroupHeader( ByVal group As Object _
,ByRef groupName As String _
,ByRef userID As String) As String
Dim key As String = groupName & userID
If Not group Is Nothing Then
Dim g As String = CType(group, String)
If Not (ht.ContainsKey(key)) Then
' must be the first pass so set the current group to group
ht.Add(key, g)
Else
If Not (ht(key).Equals(g)) Then
ht(key) = g
End If
End If
End If
Return ht(key)
End Function
Using this exprssion in the textbox of the reportheader:
=Code.SetGroupHeader(ReportItems!Language.Value,"GroupName", User!UserID)
Links belowe about the hashtable and the mutiple threads safe problem for your reference:
http://stackoverflow.com/questions/2067537/ssrs-code-shared-variables-and-simultaneous-report-execution
http://sqlserverbiblog.wordpress.com/2011/10/10/using-custom-code-functions-in-reporting-services-reports/
If you still have any problem, please feel free to ask.
Regards
Vicky Liu

Thread safe do-all class

Hi,
I'm new to Java programming and I've read through the forums and the numerous technical documents Sun has provided on how to make a GUI thread-safe. With what I've been able to understand, I created some template classes to handle the proper creation of JFrames, so I don't have to worry about playing with threads all the time. (I am operating under the assumption that invokeLater should handle the creation of all frames, not just the first window of the application).
Since I'm not completely confident I've grasped the point, I was wondering if someone could look at this code to see if I've got the right idea. Your help would be much appreciated.
Test.java
import frames.*;
public class Test
     public static void main(String args[])
          FrameOptions frameOpts = new FrameOptions("Options Window", 300, 400, true);
frames\FrameOptions.java
package frames;
public class FrameOptions extends FrameTemplate
     public FrameOptions(String title, int width, int height, final boolean visible)
          super(title, width, height);
          javax.swing.SwingUtilities.invokeLater     (     new Runnable()
                                             public void run()
                                                  createAndShow(visible);
     public void createAndShow(boolean visible)
          //Add all Swing components here.
          finishCreateAndShow(visible);
frames\FrameTemplate.java
package frames;
import java.awt.Dimension;
import javax.swing.JFrame;
public class FrameTemplate extends JFrame
     public FrameTemplate(String title)
          super(title);
     public FrameTemplate(String title, int width, int height)
          super(title);
          doSize(width, height);
     private void doSize(int width, int height)
          Dimension d = new Dimension(width, height);
          setMinimumSize(d);
          setPreferredSize(d);
     protected void finishCreateAndShow(boolean visible)
          pack();
          setVisible(visible);
}

OK, makes sense now.
For anyone else who may be new and wondering about this, this can be summed up as follows.
Summary 1:
If you create new frames from things such as menu events, you do not need to use invokeLater. Events are automatically done in the GUI thread/event dispatching thread. But if you're spawning these things from main() (or anything else not running in the EDT), you do.
If you're ever unsure of which thread a block of code is running in, just drop a System.out.println(javax.swing.SwingUtilities.isEventDispatchThread()); into it.
Summary 2:
Don't use those classes I wrote. They're rather pointless unless you're spawning all of your frames from main, which I suspect most people would not be doing.
Thanks for the clarification.
public static void main(String args[])
is run in a separate thread (separate from the GUi
i thread). So if you need to do painting or other
swing stuff from inside the main method, just use an
invoke later. If you create a new frame from the GUI
thread, you don't need to invoke later. Only if you
do it from the main method (or some other non-GUI
thread). Hope that helps

Thread safe doubt

Hi every1
My question:
Multiple threads enter the method att()...i want to count how much time does attacher.attach() method takes for every thread that comes in...i think the code below works... but if i declared the timeTakenForAttach as global variable..someone told me its not thread safe...can some1 please explain me the meaning of all this OR can i declare timeTakenForAttach as global and it won't be a problem..
class A{
long totalAttachSetupMillis=0L;
public void att() {
      long start = System.currentTimeMillis();
               attacher.attach();
      long timeTakenForAttach = System.currentTimeMillis() - start;
       recordAttachSuccess (timeTakenForAttach);
   public synchronized void recordAttachSuccess(long timeForAttach){
          totalAttachSetupMillis += timeForAttach;
}Thankyou..

javanewbie83 wrote:
I have to sychronize record sucess as different threads would enter att() and enter record success method and simultaneously update, so i will end up getting a wrong value.Let me give you a more detailed explanation of why NOT having it synchronized would not work.
First of all, let's take a look at the statement of concern:
totalAttachSetupMillis += timeForAttach;For the purposes of synchronization, however, we need to look at it like this:
int temp = totalAttachSetupMillis + timeForAttach; //call this LINE A
totalAttachSetupMillis = temp; //call this LINE BNow, lets say we had threads named 1 and 2. If you didn't sychronize the method, you could possibly have this execution flow:
//initial values: totalAttachSetupMillis = 0, timeForAttack(1) = 20, timeForAttack(2) = 30. Total should be 50
1A //temp(1) = 0 + 20 = 20
2A //temp(2) = 0 + 30 = 30 (remember totalAttachSetupMillis isn't set until B)
2B //totalAttachSetupMillis = temp(2) = 30
1B //totalAttachSetupMillis = temp(1) = 20 (instead of 50)In other words, total disaster could possibly ensue. Which is why you wanted to synchronize it. Ed's explanation of your other question was right on the money, though.

Java.util.Locale not thread-safe !

In multithreading programming, we know that double-checking idiom is broken. But lots of code, even in sun java core libraries, are written using this idiom, like the class "java.util.Locale".
I have submitted this bug report just now,
but I wanted to have your opinion about this.
Don't you think a complete review of the source code of the core libraries is necessary ?
java.util.Locale seems not to be thread safe, as I look at the source code.
The static method getDefault() is not synchronized.
The code is as follows:
public static Locale getDefault() {
// do not synchronize this method - see 4071298
// it's OK if more than one default locale happens to be created
if (defaultLocale == null) {
// ... do something ...
defaultLocale = new Locale(language, country, variant);
return defaultLocale;
This method seems to have been synchronized in the past, but the bug report 4071298 removed the "synchronized" modifier.
The problem is that for multiprocessor machines, each processor having its own cache, the data in these caches are never synchronized with the main memory.
The lack of a memory barrier, that is provided normally by the "synchronized" modifier, can make a thread read an incompletely initialized Locale instance referenced by the static private variable "defaultlocale".
This problem is well explained in http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double.html and other documents about multithreading.
I think this method must just be synchronized again.

Shankar, I understand that this is something books and articles about multithreading don't talk much about, because for marketing reasons, multithreading is supposed to be very simple.
It absolutely not the case.
Multithreading IS a most difficult topic.
First, you must be aware that each processor has its own high-speed cache memory, much faster than the main memory.
This cache is made of a mixture of registers and L1/L2/L3 caches.
Suppose we have a program with a shared variable "public static int a = 0;".
On a multiprocessor system, suppose that a thread TA running on processor P1 assign a value to this variable "a=33;".
The write is done to the cache of P1, but not in the main memory.
Now, a second thread TB running on processor P2 reads this variable with "System.out.prinln(a);".
The value of "a" is retrieved from main memory, and is 0 !
The value 33 is in the cache of P1, not in main memory where its value is still 0, because the cache of P1 has not been flushed.
When you are using BufferedOutputStream, you use the "flush()" method to flush the buffer, and the "synch()" method to commit data to disk.
With memory, it is the same thing.
The java "synchronized" keyword is not only a streetlight to regulate traffic, it is also a "memory barrier".
The opening brace "{" of a synchronized block writes the data of the processor cache into the main memory.
Then, the cache is emptied, so that stale values of other data don't remain here.
Inside the "synchronized" block, the thread must thus retrieve fresh values from main memory.
At the closing brace "}", data in the processor cache is written to main memory.
The word "synchronized" has the same meaning as the "sync()" method of FileDescriptor class, which writes data physically to disk.
You see, it is really a cache communication problem, and the synchronized blocks allows us to devise a kind of data transfer protocol between main memory and the multiple processor local caches.
The hardware does not do this memory reconciliation for you. You must do it yourself using "synchronized" block.
Besides, inside a synchronized block, the processor ( or compiler ) feels free to write data in any order it feels most appropriate.
It can thus reorder assignments and instruction.
It is like the elevator algorithm used when you store data into a hard disk.
Writes are reordered so that they can be retrieved more efficiently by one sweep or the magnetic head.
This reordering, as well as the arbitrary moment the processor decides to reconciliate parts of its cache to main memory ( if you don't use synchronized ) are the source of the problem.
A thread TB on processor P2 can retrieve a non-null pointer, and retrieve this object from main memory, where it is not yet initialized.
It has been initialized in the cache of P1 by TA, though, but TB doen't see it.
To summarize, use "synchronized" every time you access to shared variables.
There is no other way to be safe.
You get the problem, now ?
( Note that this problem has strictly nothing to do with the atomicity issue, but most people tend to mix the two topics...
Besides, as each access to a shared variable must be done inside a synchronized block, the issue of atomicity is not important at all.
Why would you care about atomicity if you can get a stale value ?
The only case where atomicity is important is when multiple threads access a single shared variable not in synchronized block. In this case, the variable must be declared volatile, which in theory synchronizes main and cache memory, and make even long and double atomic, but as it is broken in lots of implementation, ... )

BC4J View not Thread safe, user sessions are using the same view instance

Hi There,
We are using BC4J that came with JDeveloper 10.1.2.0.0 with Oracle 10G 10.1.2.0.0.
I have an BC4J account search view (BC4J AccountSearchView) that users can call to search for an account. So this view could be used by numerous users and pieces of code at the same time. Now my understanding is that each user gets their own instance of the view so changing the view's query should not be an issue (since the view definition is not changing). Under a light load the account search view looks like everyone get there own instance of the view and there expected account search results. But under a heavy user load when we have User A and User B the search query that was for User A will be used by User B. So the user results for one user will get the other users results.
I do not understand if the view definition is been changed by the other user and is impacting all view instances. How can this occur if it is thread safe?
I have enclosed the core code for this search.
If you can help that would be much appreciated, thanks in advance,
Nigel
accountSearchView.setQuery(baseSelectQuery+generateWhereClause());
logger.debug("SearchAccounts Query: "+accountSearchView.getQuery());
System.out.println("SearchAccounts SQL: "+accountSearchView.getQuery());
accountSearchView.setPassivationEnabled(false);
accountSearchView.setForwardOnly(true);
accountSearchView.executeQuery();
get attributes for each row result and place in new Java bean objects and return to user.

Nigel, we've only certified JDeveloper 10.1.2 against the Struts 1.1 with which it ships.
If there have been any changes in Struts 1.2 to the Struts Request Processor, then this could easily have an impact on the BC4JRequestProcessor's correct functioning, depending on what the changes were.
My quick look into the issue tells me that the ActionServlet init parameter named mapping in web.xml that we use for the 9.0.3-style BC4J/Struts integration is getting ignored by Struts 1.2. This parameter is used by Struts 1.1 to globally configure a custom ActionMapping subclass which can support additional properties. My quick test shows me that Struts 1.2 is ignoring this setting and so the oracle.jbo.html.struts11.BC4JActionMapping subclass of Struts's default ActionMapping is not getting used correctly as it does in Struts 1.1. This leads to errors when Struts tries to configure its actions in struts-config.xml since the Apache digester tries to set properties on the ActionMapping instance that don't exist (since the BC4JActionMapping has these properties, and it's not being used).
<servlet>
    <servlet-name>action</servlet-name>
    <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
    <init-param>
      <param-name>mapping</param-name>
      <param-value>oracle.jbo.html.struts11.BC4JActionMapping</param-value>
    </init-param>
</servlet>This is my quick analysis of what's not out-of-the-box compatible. I don't know enough about the changes in Struts 1.2 to know why this Struts 1.1 feature broke in Struts 1.2, or what the Struts 1.2 way to accomplish the same thing is.
I'd encourage you to use Worldwide Support's Metalink site and open a TAR for any time-critical issues you need assistance in resolving. Many of us are constantly traveling and only able to sporadically chime in with tips in the forum as our time permits.
The source of the BC4JRequestProcessor ships with the produce in the ./BC4J/src directory inside the bc4jstrutssrc.zip file.

JTextArea: Not thread safe

I am working on a lobby system with a chat are using Networking, and recently I noticed that occasionally my JTextArea does not append the data I give it, even if I have a System.out.println() directly before which shows me what it is being passed, and it is being passed correct Strings, it is just not appending them.
    Thread updateText = new Thread() {
        public void run()
            for(;;)
                try {
                    for (int x = 0; x < texts.size(); x++) {
                        System.out.println("ADDED: "+texts.get(x));
                        textArea.append(texts.get(x));
                    texts.clear();
                    scrollToEnd(textArea);
                    Thread.sleep(100);
                } catch (InterruptedException ex) {
                    Logger.getLogger(Main.class.getName()).log(Level.SEVERE, null, ex);
    };I have an ArrayList texts, which keeps track of what is being typed into the Chat Area. This code displays correctly What I want it to, i.e. "ADDED: Hello guys, etc.", however the JTextArea does not update. Is there something to make the JTextArea thread-safe because I have heard on several sites that JTextAreas are not thread-safe.
Any help would be greatly appreciated.

I changed my code to this: and now it does not work at all, i.e., the JTextArea never updates:
    Thread updateText = new Thread() {
        public void run()
            for(;;)
                try {
                    SwingUtilities.invokeAndWait(update);
                } catch (InterruptedException ex) {
                    Logger.getLogger(Main.class.getName()).log(Level.SEVERE, null, ex);
                } catch (InvocationTargetException ex) {
                    Logger.getLogger(Main.class.getName()).log(Level.SEVERE, null, ex);
    Runnable update = new Runnable() {
        public void run()
            try {
                texts.clear();
                scrollToEnd(textArea);
                for (int x = 0; x < texts.size(); x++) {
                    System.out.println("ADDED: " + texts.get(x));
                    textArea.append(texts.get(x));
                Thread.sleep(100);
            } catch (InterruptedException ex) {
                Logger.getLogger(Main.class.getName()).log(Level.SEVERE, null, ex);
    };

Trying to understand "thread-safe" w/ swing components

The other day there was a big hullabaloo about some code I posted because I was calling JLabel.setText from a thread that wasn't the ui thread. On the other hand, this thread was the only thread making changes to the JLabel. My understanding is that in any kind of multi-threaded system, if you just have 1 writer / changer, then no matter how many readers there are, this is thread-safe. So why what I was doing not thread safe?
Second question - JLabel.setText() is essentially setting data in the model for JLabel, which then gets picked up and displayed the next time the GUI thread paints it. So if it's not safe to update a JLabel's model, I assume its never safe to update any data that also is being displayed visually. So for instance, if I was showing some database table data in a JTable, I should do the update in the UI thread - probably not. But what is the distinction?
Third question - what swing components and what operations need to be run on the UI thread to call your program "thread-safe". Validate? setSize()? setLocation()? add? remove? Is there anything that can be called on swing components from a non-ui thread?
Edited by: tjacobs01 on Nov 2, 2008 8:29 PM

tjacobs01 wrote:
My understanding is that in any kind of multi-threaded system, if you just have 1 writer / changer, then no matter how many readers there are, this is thread-safe. So why what I was doing not thread safe?This is not true. As I mentioned in that hullabaloo thread, the Java Memory Model allows threads to cache values of variables they use. This means that values written by one thread are not guaranteed to ever be visible to other threads, unless you use proper synchronization.
Take the following example:
import java.util.concurrent.TimeUnit;
public class ThreadExample {
    static class Foo {
        private String value = "A";
        public String getValue() {
            return value;
        public void setValue(String value) {
            this.value = value;
    public static void main(String[] args) {
        final Foo foo = new Foo();
        Thread writer = new Thread() {
            @Override
            public void run() {
                try {
                    TimeUnit.SECONDS.sleep(1);
                    foo.setValue("B");
                } catch (InterruptedException e) {
                    e.printStackTrace();
        Thread reader = new Thread() {
            @Override
            public void run() {
                try {
                    TimeUnit.MINUTES.sleep(1);
                    System.out.println(foo.getValue());
                } catch (InterruptedException e) {
                    e.printStackTrace();
        writer.start();
        reader.start();
}Here two different threads both access the same Foo instance, which is initialized with a value of "A". One thread, the writer, sleeps one second, and then sets foo's value to "B". The other thread, the reader, sleeps one minute (to avoid race conditions) and then prints foo's value to System.out. It may seem obvious that the reader thread will read the value "B", but this is in fact not guaranteed to be true. The reader thread may never see the value that was written by the writer thread, so it may very well read the old value "A".
(If you run the code you will probably see "B" printed out, but again, this is not guaranteed behavior.)
A simple way to fix this is to synchronize access to the mutable state that the two threads share. For example, change the class Foo to
    static class Foo {
        private String value = "A";
        public synchronized String getValue() {
            return value;
        public synchronized void setValue(String value) {
            this.value = value;
    }It's for this same reason that you often see the use of a volatile boolean as a control flag for stopping threads, rather than a plain old boolean. The use of volatile guarantees that the thread you want to stop actually sees the new value of the flag once it has been set by another thread.
Here is an article that touches some of this stuff:
[http://www.ibm.com/developerworks/java/library/j-jtp02244.html]
I also highly recommend the book "Java Concurrency in Practice" (one of the authors of which, David Holmes, sometime hangs out on the Concurrency forum here, I believe).
Edited by: Torgil on Nov 2, 2008 9:01 PM

How to know whether a method is thread-safe through the java-doc?

In some book, it says that SAXParserFactory.newSAXParser() is thread-safe,but in the java-doc,it doesn't say that.
newSAXParser
public abstract SAXParser newSAXParser()
throws ParserConfigurationException,
SAXExceptionCreates a new instance of a SAXParser using the currently configured factory parameters.
Returns:
A new instance of a SAXParser.
Throws:
ParserConfigurationException - if a parser cannot be created which satisfies the requested configuration.
SAXException - for SAX errors.
I want to know, how to know whether a method is thread-safe?

System.out is a PrintStream object. None of the methods there use the synchronized modifier, but if you look in the source code, you will find out it is thread-safe, because it will use synchronized blocks whenever it writes some text.
The source code is in the src.jar file which you can extract.
I didn't find any comments about that PrintStream is thread-safe in the API.

How can I get to know if a method is threads-safe?

Hi, there.
How can I get to know if a method is threads-safe?
For example, in two different threads, is System.out.print() method safe or not?And where can I find the information with regard to this?
thanks very much.

System.out is a PrintStream object. None of the methods there use the synchronized modifier, but if you look in the source code, you will find out it is thread-safe, because it will use synchronized blocks whenever it writes some text.
The source code is in the src.jar file which you can extract.
I didn't find any comments about that PrintStream is thread-safe in the API.

Is abap thread safe? Some question in Singleton pattern in ABAP

Hi Grus,
I have a very basic question but really make me headache...
Recently I am learning the design pattern in ABAP and as you know in JAVA there is a key word "Synchronized" to keep thread safe. But in ABAP, I didn't find any key words like that. So does that mean ABAP is always a single thread language? And I found that there is a way looks like "CALL FUNCTION Remotefunction STARTING NEW TASK Taskname DESTINATION dest" to make multi-thread works. As you can see it use the destination, so does that mean actually the function module is always executed in a remote system, and in every system, it is always single thread?
Could you help me on the question? Thanks a lot, grus
And here comes up to my mind another question...It's a little bit mad but I think it may works....What if I set every attribute and method as static in the singleton class...Since as you can see it is already a singleton so every attribute in it should be only one piece. So then I don't even need to implement a get_instance( ) method to return the instance. Just call "class_name=>some_method( )" directly then singleton is achieved...What do you think?
BR,
Steve

Steve,
I've the same question, few days ago I tried to use the singleton in ABAP. In Java programming is possible to use the same reference in two sessions or programs, sharing attributes, methods and all data, but I could not do in ABAP.
In my test I created a program with one global class using the singleton pattern, so I expected that when I run my program and see the reference returned after the get_instance method it should be equal to the same program run in another session, but the ABAP will create a new reference and instantiate again.
So I deduced that the only way to share it between sessions in ABAP is using the ABAP Shared Memory Objects.
I can be wrong, but I think that ABAP use a thread by user session (Each window) and we can't change it.
Best regards.

Is System.arraycopy thread safe?

Similar Messages

Maybe you are looking for