Is the Memory Suite thread safe?
Hi all,
Is the memory suite thread safe (at least when used from the Exporter context)?
I ask because I have many threads getting and freeing memory and I've found that I get back null sometimes. This, I suspect, is the problem that's all the talk in the user forum with CS6 crashing with CUDA enabled. I'm starting to suspect that there is a memory management problem when there is also a lot of memory allocation and freeing going on by the CUDA driver. It seems that the faster the nVidia card the more likely it is to crash. That would suggest the CUDA driver (ie the code that manages the scheduling of the CUDA kernels) is in some way coupled to the memory use by Adobe or by Windows alloc|free too.
I replaced the memory functions with _aligned_malloc|free and it seems far more reliable. Maybe it's because the OS malloc|free are thread safe or maybe it's because it's pulling from a different pool of memory (vs the Memory Suite's pool or the CUDA pool)
comments?
Edward
Zac Lam wrote:
The Memory Suite does pull from a specific memory pool that is set based on the user-specified Memory settings in the Preferences. If you use standard OS calls, then you could end up allocating memory beyond the user-specified settings, whereas using the Memory Suite will help you stick to the Memory settings in the Preferences.
When you get back NULL when allocating memory, are you hitting the upper boundaries of your memory usage? Are you getting any error code returned from the function calls themselves?
I am not hitting the upper memory bounds - I have several customers that have 10's of Gb free.
There is no error return code from the ->NewPtr() call.
PrMemoryPtr (*NewPtr)(csSDK_uint32 byteCount);
A NULL pointer is how you detect a problem.
Note that changing the size of the ->ReserveMemory() doesn't seem to make any difference as to whether you'll get a memory ptr or NULL back.
btw my NewPtr size is either
W x H x sizeof(PrPixelFormat_YUVA4444_32f)
W x H x sizeof(PrPixelFormat_YUVA4444_8u)
and happens concurrently on #cpu's threads (eg 16 to 32 instances at once is pretty common).
The more processing power that the nVidia card has seems to make it fall over faster.
eg I don't see it at all on a GTS 250 but do on a GTX 480, Quadro 4000 & 5000 and GTX 660
I think there is a threading issue and an issue with the Memory Suite's pool and how it interacts with the CUDA memory pool. - note that CUDA sets RESERVED (aka locked) memory which can easily cause a fragmenting problem if you're not using the OS memory handler.
Similar Messages
-
Is the Illustrator SDK thread-safe?
After searching this forum and the Illustrator SDK documentation, I can't find any references to a discussion about threading issues using the Illustrator C++ SDK. There is only a reference in some header files as to whether menu text is threaded, without any explanation.
I take this to mean that probably the Illustrator SDK is not "thread-safe" (i.e., it is not safe to make API calls from arbitrary threads; you should only call the API from the thread that calls into your plug-in). Does anyone know this to be the case, or not?
If it is the case, the normal way I'd write a plug-in to respond to requests from other applications for drawing services would be through a mutex-protected queue. In other words, when Illustrator calls the plug-in at application startup time, the plug-in could set up a mutually exclusive lock (a mutex), start a thread that could respond to requests from other applications, and request periodic idle processing time from the application. When such a request arrived from another application at an arbitrary time, the thread could respond by locking the queue, adding a request to the queue for drawing services in some format that the plug-in would define, and unlocking the queue. The next time the application called the plugin with an idle event, the queue could be locked, pulled from, and unlocked. Whatever request had been pulled could then be serviced with Illustrator API calls. Does anyone know whether that is a workable strategy for Illustrator?
I assume it probably is, because that seems to be the way the ScriptingSupport.aip plug-in works. I did a simple test with three instances of a Visual Basic generated EXE file. All three were able to make overlapping requests to Illustrator, and each request was worked upon in turn, with intermediate results from each request arriving in turn. This was a simple test to add some "Hello, World" text and export some jpegs,
repeatedly.
Any advice would be greatly appreciated!
Glenn Picher
Dirigo Multimedia, Inc.
[email protected]Zac Lam wrote:
The Memory Suite does pull from a specific memory pool that is set based on the user-specified Memory settings in the Preferences. If you use standard OS calls, then you could end up allocating memory beyond the user-specified settings, whereas using the Memory Suite will help you stick to the Memory settings in the Preferences.
When you get back NULL when allocating memory, are you hitting the upper boundaries of your memory usage? Are you getting any error code returned from the function calls themselves?
I am not hitting the upper memory bounds - I have several customers that have 10's of Gb free.
There is no error return code from the ->NewPtr() call.
PrMemoryPtr (*NewPtr)(csSDK_uint32 byteCount);
A NULL pointer is how you detect a problem.
Note that changing the size of the ->ReserveMemory() doesn't seem to make any difference as to whether you'll get a memory ptr or NULL back.
btw my NewPtr size is either
W x H x sizeof(PrPixelFormat_YUVA4444_32f)
W x H x sizeof(PrPixelFormat_YUVA4444_8u)
and happens concurrently on #cpu's threads (eg 16 to 32 instances at once is pretty common).
The more processing power that the nVidia card has seems to make it fall over faster.
eg I don't see it at all on a GTS 250 but do on a GTX 480, Quadro 4000 & 5000 and GTX 660
I think there is a threading issue and an issue with the Memory Suite's pool and how it interacts with the CUDA memory pool. - note that CUDA sets RESERVED (aka locked) memory which can easily cause a fragmenting problem if you're not using the OS memory handler. -
Are methods in the Graphics class Thread Safe
Can methods from the Graphics class (.e.g. drawImage(), drawString(), ect..) be called from any thread? In other words, can two threads that refer to the same Graphics object step on each other methods calls?
TIA,
DB
Edited by: Darth_Bane on Apr 27, 2009 1:44 PMNo,
They are GUI activities so you should call them from the Swing Thread ( Event Disptach Thread)
Now for the JComponent the following are thread safe:
repaint(), revalidate, invalidate which can be called from any thread.
Also the listener list can be modified from any thread addListenerXX or removeListenerXX where XX is ListenerType
Regards,
Alan Mehio
London, UK -
Is the reflection API thread safe?
The obvious answer would appear to be yes, however, I have not been able to find any supporting documentation.
I need to call the newInstance(Object[] initArgs) method on the same instance of the Constructor class from multiple threads.Hi,
without knowing the reflection API too well, my guess would be, you are ok. If several threads are
just creating new instances and you are not modifying anything used in their constructors, no problem.
However, if you have a thread changing some class variables that are used in turn by the constructors to
initialize the instances, you are in trouble.
In such a case, try to encapsulate read&write access to these variables in synchronized
methods (setter/getter).
Good luck!
Pete -
Is the standard C++ library provided in Solaris 9 thread-safe?
Hi,
I cannot find any documentation anywhere that says that the standard C++ library in Solaris 9 (provided by Rogue Wave) is thread safe.
I have seen evidence that makes me think it is not - however, I was wondering if anyone could provide any insight. If they are not, where could I obtain the libraries that are thread safe?
The libraries of interest are:
/lib/sparcv9/libCstd.so.1 &
/lib/sparcv9/libCrun.so.1
Thankyou in advance.Whether the library is thread safe depends on what you mean by thread safety. Except for the 8 standard iostream objects (std::cin, std::cout, etc.), simultaneous accesses from multiple threads to all objects of standard library types must be synchronized by the user. E.g., it's not safe to read or write the same container object (e.g., std::vector, or std::string) from multiple threads at the same time. The C++ localization library imposes some additional restrictions because of its interactions with the global C locale.
-
Are static nested classes thread-safe?
There doesn't seem to be any definitive answer to this. Given the following code, is it thread-safe?
public class SomeMultiThreadedWebController {
public HttpServletResponse someMethodToExecuteViaWebRequest(HttpServletRequest request) {
simpleQueryBuilder("SELECT...").addParameter("asdf","asdf").createQuery(EMF.getEntityManager()).executeUpdate();
protected static class SimpleQueryBuilder {
private String queryString;
private Map<String, Object> params = new HashMap<String, Object>();
public SimpleQueryBuilder(String queryString) {
this.queryString = queryString;
public SimpleQueryBuilder addParameter(String name, Object value) {
params.put(name, value);
return this;
public Query createQuery(EntityManager em) {
Query query = em.createQuery(queryString);
for (Entry<String, Object> entry : params.entrySet()) {
query.setParameter(entry.getKey(), entry.getValue());
return query;
public static SimpleQueryBuilder simpleQueryBuilder(String queryString) {
return new SimpleQueryBuilder(queryString);
}Forget whether or not someone would do this, as this is just an example. I'm really trying to get at whether or not the instance variables inside the static nested class are thread-safe. Thanks for any responses.Hello,
I believe you understand what you're talking about, but you state it in a way that is very confusing for others.
Let me correct this (essentially, incorrect uses of the terminology):
I agree that thread-safe or not is for an operation, for a member, it has some sort of contextual confusion.
Member has a much broader meaning in the [Java Language Specification|http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.4] . Even "class member" applies to both an attribute, a method, or an inner class or interface.
I think you mean "member variable" of a class (aka "attribute" or "field"). By the way, static or not is irrelevant to the rest of the discussion.
For an operation or a member, if there's only one thread could access it atomically in one moment, we could call it thread-safe.Mmm. I was tempted to say yes (I'm reluctant to commit myself). With an emphasis on "_The encapsulating class_ makes this member's usage thread-safe".
Still, just synchronizing each operation on a member is not enough to make all usages "thread-safe":
Consider a java.util.Vector: each add/get is synchronized, so it is atomic, fine.
However if one thread adds several values, let's say 3, one by one, to a vector that initially contains 0 values, and another thread reads the vector's size() (another properly synchronized method), the reader thread may witness a size anywhere among 0, 1, 2, 3, which, depending on the business logic, may be a severely inconsistent state.
The client code would have to make extra work (e.g. synchronizing on the vector's reference before the 3 adds) to guarantee that the usage is thread-safe.
Thus any synchronized method(With the limit stated above)
or immutable member (like primitive type) are thread-safe.
Additionally for a member, if it's immutable, then it's thread-safe. You mean, immutable primitive type, or immutable object. As stated previously, an immutable reference to a mutable object isn't thread-safe.
a static final HashMap still have thread-safe issue in practice because it's not a primitive.The underlined part is incorrect. A primitive may have thread-safety issues (unless it's immutable), and an object may not have such issues, depending on a number of factors.
The put, get methods, which will be invoked probably, are not thread-safe although the reference to map is.Yes. And even if the put/get methods were synchronized, the client code could see consistency issues in a concurrent scenario, as demonstrated above.
Additional considerations:
1) read/write of primitive types are not necessarily atomic: section [ §17.7 of the JLS|http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.7] explicitly states that writing a long or double value (2 32-bits words) may not be atomic, and may be subject to consistency issues in a concurrent scenario.
2) The Java Memory Model explicitly allows non-synchronized operations on non-volatile fields to be implemented in a "thread-unsafe" way by the JVM. Leading way to a lot of unintuitive problems such as the "Double-Checked Locking idiom is broken". Don't make clever guess on code execution path unless you properly synchronize access to variables across threads.
Edited by: jduprez on Mar 4, 2010 9:53 AM -
My business logic bean is being accessed via jsp's
It looks something like this
public class MyBean
private int myInt;
private String MySting;
* Bean sets and gets
public void setMyInt(int i)
myInt = i;
public void setMyString (String s)
myString = s;
public int getMyInt()
return myInt;
public String getMyString()
return myString;
* Public wrapper for private business logic
public void doSomethingWrapper()
myString = doSomething(getMyInt())
* Private business logic
private String doSomething(int i)
// business Logic
return a_string;
Now, I've been told that this is not thread safe and that will not work. My big concern is
with making the Bean properties thread safe, anyone way any suggestions? Thanks in advance.Based on your requirement, i see a necessicity for session scoping the bean.
And yes in servlet/jsp multiple thread can act on single instance of a bean.
So what you do is add synchronized keyword for the getter and setter method. For example if have modify your example given above, it would look something like this
public class MyBean
private int myInt;
private String MySting;
* Bean sets and gets
public synchronized void setMyInt(int i)
myInt = i;
public synchronized void setMyString (String s)
myString = s;
public synchronized int getMyInt()
return myInt;
public synchronized String getMyString()
return myString;
* Public wrapper for private business logic
* You dont necessarily have to synchronze this method because
* getMyInt() is anyway synchronized.
public void doSomethingWrapper()
myString = doSomething(getMyInt())
* Private business logic
* If you dont access any properties(member variables) dont synchronize, if you do then yes
private String doSomething(int i)
// business Logic
return a_string;
}By adding synchronized keyword the java virtual machine ensures method level serial execution, so no corruption problem.
But you require more than method level synchronization, then you need some other mechanism like semaphore and just.
In most of the case, former would be just enough but if your case is not so then let me know, I can suggest other mechanism which suit your needs -
Thread safe logging class, using final and static
Hi,
I'm looking through a logging class (which writes entries to a text file and so on) written by someone else, and I'm trying to determine whether it's thread-safe...
Essentially the class looks like this:
public final class Logger {
private static FileOutputStream fout;
private static PrinterWriter pout;
private static final long MaxLength = 100000;
static {
/* basically checks size of logfile, if bigger than 100k, then copy it as bak, and start again */
public void write(String msg) {
/* write entry into log file */
public void writeWithTimeStamp(string msg) {
/* write entry with time stamp into log file */
Now, I could be wrong, but I don't think that the class is thread-safe is it? in order to be thread-safe, I would have to use synchronized before write() and writeWithTimeStamp(), right?
My confusion arises from the use of the keyword "final" at the top of the class. This class isn't being inherited (or rather, there's no reason for the class not to be inheritable)... so what is it's purpose, if there is one?!
And my other question concerns the static block. But I need to describe the current setup first: The Logger class is being use by a file server. File server basically sits there, accepts socket connections from the outside, and takes text files and output them into a local directory. When a new socket connection is created, a new thread is created. As it stands right now, each thread instantiates its own Logger object which seems weird! Bringing me to my question which was, if each thread instantiates its own Logger object, the static block is only ran ONCE, regardless of how many threads (and therefore Logger objects) are created, right??
And wouldn't it be a better idea to simply create only ONE Logger object and pass it by reference to all newly created threads as they are needed so that all threads access the same and only Logger object? (and therefore utilize sychronization)
Thanks!In JDK 1.4, there are already classes written that do all of that work. Check out the docs for the java.util.logging package. Specifically, check out FileHandler (which can rotate log files if they are greater than a specified size) and LogRecord (which is a standardized way to store logging entries). I believe the class is threadsafe, it doesn't say it isn't. Try it and see. If not, you can easily make a threadsafe wrapper for it (or any class for that matter).
The online documentation is at:
http://java.sun.com/j2se/1.4/docs/api/index.html
If you are curious, the simplest way to make any class threadsafe, if you don't want to or are not able to modify the class code itself is to define another class that calls methods of the original class, but that is synchronized.
Example:
// NonThreadSafe.java
public class NonThreadSafe {
public NonThreadSafe (String s) {
// Constructor
public void SomeMethod (int param) {
// Do some important stuff here...
public int AnotherMethod (boolean param) {
// Do some more important stuff here...
// ThreadSafeWrapper.java
public class ThreadSafeWrapper {
protected NonThreadSafe nts;
public ThreadSafeWrapper (String s) {
nts = new NonThreadSafe(s);
public synchronized void SomeMethod (int param) {
nts.SomeMethod(param);
public synchronized int AnotherMethod (boolean param) {
return nts.AnotherMethod(param);
public NonThreadSafe GetNonThreadSafe () {
return nts;
};Unfortunately, ThreadSafeWrapper isn't derived from NonThreadSafe, so you are somewhat limited in what you can do with it compared to what you could do with NonThreadSafe. AFAIK, you can't override unsynchronized methods with synchronized ones.
Another thing you could do is just write a method that writes to your logging class, and synchronize just that method. For example:
// ThreadSafeLogger.java
public class ThreadSafeLogger {
public static synchronized void LogMessage (MyLogger log, String msg) {
log.writeString(msg);
// In another thread, far, far away:
ThreadSafeLogger.LogMessage(theLog, "Blah");
...Hope that helps.
Jason Cipriani
[email protected]
[email protected] -
Are CacheStore's and BackingMapListener's thread safe?
I'm implementing a JMS CacheStore and have a quick question: does Coherence ever attempt to run multiple threads concurrently across a CacheStore instance on a given node?
Reason I ask is that only certain objects are thread-safe in the JMS spec.: Connection Factories, Destinations (i.e. a Queue) and Connections. However Sessions, Producers and Consumers are not.
In order to improve performance, it's recommended (obviously) to try and reuse Sessions/Producers and not recreate them for every message sent. So I'd like to declare them as instance variables in my class and assign them once-only at construction time.
I just wanted to make sure that this would be OK (i.e. Coherence would start multiple threads running across my CacheStore). Anyone any ideas?
(NB. I'm using JMS Connection Pooling to get around this issue at the moment - as the pools are thread-safe and I can close/open them quickly as many times as I like - but this is not a part of the JMS standard, so I end up using vendor-specific classes which I'd rather not do. Likewise I could make many of these non-thread-safe objects use ThreadLocals, but this all seems a bit overkill if it isn't actually required...)
An other issue... :)
What about closing the connection when it's finished with? Again, it's JMS recommended best-practice to do so. How is this best accomplished, seem as though it was Coherence that created the CacheStore instance and my client code has no reference to it? Best I can think of for now is have a static method in my CacheStore class that is kicked off via an invocation-service agent. Again, if anyone has a better idea I'm all ears.
An other issue... :)
Does the same thread-safety hit BackMapListeners? The "receiving" end of my JMS messages is a BackingMapListener based on the Incubator Commons "AbstractMultiplexingBackingMapListener" class. So, does Coherence ever kick off multiple threads across a single BackingMapListener instance, or can I safely have the JMS Session and Consumer left open after construction as class-level members?
Cheers,
Stevestevephe wrote:
True... But I was rather hoping I could just get someone from Oracle who wrote the stuff to comment instead! :) Don't really want to second-guess this, as there could always be unusual corner-cases that could be difficult to replicate. Still...
I did a bit more testing on my CacheStore this morning. I removed the non JMS-standard "pooling" and just created instance variables for only those items which I know to be thread-safe (ConnectionFactory, Connection and my target queue, a "Destination" in JMS terminology) I now re-get the Session and Producer in each Cachestore method. This makes the code thread-safe and portable. TBH, it hasn't affected performance too much, so I'll leave it as it is for now (and I've put a comment in the code stating that people could move these things to ThreadLocal's if they wanted to further boost performance in their own usage cases and still keep the CacheStore thread-safe.)
As regards the "receiving" end of these published messages, my BackingMapListener does nothing more than register a JMS MessageListener and a "connection.start()" call. This is a very short, one-off call, so shouldn't leave Coherence service threads "hanging" on anything for extended periods.
Cheers,
SteveHi Steve,
to cut things short:
1. Coherence instantiates one cache store per read-write-backing-map, therefore it needs to be thread-safe if you have a thread-pool or use write-behind.
2. If you don't have write-behind then Coherence uses the worker thread to execute the cache store operations.
3. If you have write-behind then generally Coherence uses the write-behind thread (this is a separate thread per write-behind-configured service) to execute the cache store operations, except for erase[All]() operations on cache.remove() or batch remove which cannot be delayed due to consistency reasons and are executed on the worker thread.
If you don't have a thread-pool, replace worker thread with service thread.
I don't know off my head where the refresh-ahead operation executes.
There is a single backing-map-listener per backing map instantiated, therefore it needs to be thread-safe. BackingMapManagerContext is thread-safe, so there is no issue with sharing it across multiple threads executing on a backing-map-listener.
Best regards,
Robert -
I got a problem? Look the class below.
=============================
public class AQuestion
private int i=0;
public void inc()
i++;
==============================
Is the method inc() thread safe?
What I mean is that is the single line code "i++;" thread safe?I wrote a test as below.
===============================================
public class ThreadSafeTest
  private static int threadCount=100;
  private static final long loopCount=100L;
  //private static int threadCount=1000;
  //private static final long loopCount=1000000L;
  private static int finishedThreadCount=0;
  static synchronized void threadFinished()
  {
    finishedThreadCount++;
  }
  public static void main(String[] args)
  {
    final IncObj tt=new IncObj();
    long start=System.currentTimeMillis();
    for(int i=0;i<threadCount;i++)
    {
      new Thread()
      {
        public void run()
        {
          for(long j=0;j<loopCount;j++)tt.inc();
          threadFinished();
        }
      }.start();
    }
    while(finishedThreadCount<threadCount)
    {
      try{
        Thread.sleep(200L);
      }catch(Exception e){
        e.printStackTrace();
      }
    }
    long end=System.currentTimeMillis();
    System.out.println("All sub threads finished after "+(end-start)+" millisecond");
    System.out.println("the expected result is "+threadCount*loopCount);
    System.out.println("the real result is "+tt.get());
  }
class IncObj
  private int i=0;
  //public synchronized void inc()
  public void inc()
  {
    i++;
  }
  public int get()
  {
    return i;
  }
===============================================
My program runs on intel PentiumIII 500Mhz + windows XP home Edition + j2sdk1.4.0 
the result is as below.
===============================================
All sub threads finished after 241 millisecond
the expected result is 10000
the real result is 10000
===============================================
but when I commented 
  private static int threadCount=100;
  private static final long loopCount=100L;
into 
  private static int threadCount=1000;
  private static final long loopCount=1000000L;
the result is becomes
===============================================
All sub threads finished after 345717 millisecond
the expected result is 1000000000
the real result is 785277617
===============================================
when I comment 
  public void inc()
into
  public synchronized void inc()
the performance becomes unbearable.
Can I get the conclusion that "i++" is not thread safe? -
Is java.xml.parsers.DocumentBuilder Thread Safe?
Does anyone know if the DocumentBuilder is thread safe? Meaning,
can I call the parse(...) methods from several threads simultanously, without getting errors?
I would be happy if anyone can also point me to the documentation that says DocumentBuilder is or isn't thread safe.My Code Like Such:
public class DigestUtil
private static MessageDigest md_md5 = null;
static
try{
md_md5 = MessageDigest.getInstance("MD5");
}catch(Exception ex)
public static byte[] DigestMD5(byte[] b)
return b==null ? null : md_md5.digest(b);
I Don't Wish to Every Digest, Every Create MessageDigest Instance. -
Guidlines for a "thread safe" library
I am trying to use a 3rd party library for a communications board (ARINC). I asked the vendor if the library is "thread-safe" since the application is multi-threaded. He had indicated to me he didn't know how to create a thread-safe library. Are there any guidelines i can give him to help him (and eventually me) to write a library that is thread-safe?.
The application uses 5 threads to upload a program or data to a production unit via ARINC communications protocol. (Lane 1 program, Lane 2 program, Progress, Lane 1 cal, Lane 2 cal). If any interruption occurs or a bad checksum in the data flow the unit will lockup and require disassembly and low level j-tag re-programming.Never Mind -
The instrument driver development guide talks about thread protection that can be applied to a library.
Moderator - Please close/delete this topic -
Hi
Are swing comonents are thread safe ?
If i am not wrong the thread safe objects are those whose data changes are predictable ( i mean no race condition)
Is this correct ?
I had worked on multithreaded application in MFC where we used Message queues for hadling the multithreading
Can i use the same logic in java also ? If yes can anybody help me how can i do it
Thanks in advanceThe Swing tutorial on [url http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html]Using Threads explains the concept of "Thread Safe".
-
SYS-170111 - Cannot stop memory monitor thread: RWThreadImp::terminate -
Hi Experts,
WE have this warning in pretty much every job in production. But the warnings are not specific to certain jobs they might occur one day and not the other day.
Cannot stop memory monitor thread: <RWThreadImp::terminate - No thread is active within the runnable>.
I know looking at the release notes this issue was fixed in 3.0 (12.0.0), we are using 3.2 (12.2.0) and having the same issues. The job server is on a linux 64 bit. I have not seen this issue in any of our windows job server. Is this bug specific to linux or is there a resolution for this.
Appreciate your help in advance.
Thanks
AJ
Edited by: alangilbi on Sep 28, 2011 5:17 PMHi, AJ.
As can be seen in the KBA 1455412 this is a known behavior.
"As a result of fixing the problem identified in ADAPT 00890818 in release 12.0.0.0, this message is displayed by design. If there is really a problem in stopping the memory monitor thread an exception is thrown and an error message is logged.
Background:
In the memory monitor's shutdown logic, once it tells the monitor thread to shutdown it waits for the thread to terminate but only for 10 seconds. It could be that at this same time the wait expired when the thread actually terminates. So when this happens in the shutdown logic we force terminate the thread. Since there is no active thread anymore the terminate call throws an exception and then we catch it and then throws the error for the job."
You can just ignore this warning.
Leo. -
Is ThreadPoolExecutor.execute(Runnable) thread-safe?
Is ThreadPoolExecutor.execute(Runnable) thread-safe, i.e. is it safe
to invoke this method from multiple threads without making any
special arrangements to ensure that not more than one thread is
in the execute() method of the ThreadPoolExecutor object at the same time
(such as synchronizing on the ThreadPoolExecutor object)?
I can find nothing in the Java 6 documentation to say it is thread-safe
(Executor, ExecutorService, ThreadPoolExecutor and package documentation).
Note that I am not asking anything about the actual execution of the Runnables.
I am asking about the act of inserting the Runnables into the thread pool.Thanks to everyone who replied.
The three example implementations in the interface documentation for Executor, including the one where the Runnable is executed by the invoking thread, are thread-safe but only the last one needs to do anything special (namely make the execute(...) method synchronized) to be thread-safe. It is not clear whether the thread-safety of the first two implementations is conscious or accidental. Even if conscious that would not imply that it is necessary.
I think the published documentation (unless I've missed something) is deficient. The method would not be useless if not thread-safe. I don't think thread-safety is a safe default assumption. I think a package that supports concurrent programming should be clear on where it is thread-safe.
I've had a quick look at the source code in the 1.6 JDK implementation. It makes a serious and plausible effort to be thread-safe. It was written by Doug Lea.
I'm going to assume the method is thread-safe, based on looking at the source code.
Maybe you are looking for
-
Problem with image in Hierarchy Viewer component
Hi All, I am using Hierarchy Viewer component in my application developed in Jdeveloper 11.1.1.6.0 Actually, my requirement is to pick the name of the "content id" stored as a value in a field in the table. Hence written code as follows, which is not
-
Best practice for web service call
I can add a web service using the standard data connection wizard - works fine. I also can do it all in Javascript which give me a bit more flexibility. Is there some guideline or wisdom for which is best?
-
How to setup the fax function for a AOI device
I read in several post on this forum that people get full print/scan/FAX functionality for the supported printers. In my case, I have a HP Photosmart C7280, which is full supported using the C7200 series drivers, including a FAX driver. Now, I add a
-
Hi! Where can I find parts for a DR430KU DVD Video Recording unit, I'm having problems with the optical pickup unit and I need to know where can I buy parts or get service for the machine.
-
Getting error message when connecting with DI
Hi all i'm getting error code -8006 and error message: Resource Error. when i try to connect to the company db using the method connect() of the object Company. does anyone knows what causes the problem and if so how to fix it? appreciate the help Yo