Thread safe Queue implementation

Dear all,
I have implemented Queue functionality using Blocking concurent linked list based java queue, but i am facing problem of deadlock/program hang.
There are 10 threads which are trying to see that is there any object in Queue, they get that object and process it.
Any idea what is wrong ??
Thanks
public class MyQueue
    private LinkedBlockingQueue<Object> elements;
    private Object obj;
    public MyQueue() {
        elements = new LinkedBlockingQueue<Object>();
        obj=null;
    public Object pull() {
         try {
               obj = elements.take();
          } catch (InterruptedException e) {
               // TODO Auto-generated catch block
               e.printStackTrace();
          return obj;
    public void push(Object o) {
         try {
               elements.put(o);
          } catch (InterruptedException e) {
               // TODO Auto-generated catch block
               e.printStackTrace();
    public Object[] removeAllObjects() {
        Object[] x = elements.toArray();
        elements.clear();
        return x;
}

Thanks,
I analyzed the hanged/deadlocked program by killing its process with command "kil -3 <pid>"
i have seen following state for my JobHandler threads
is any wrong with Queue implementation or some thing else , Any idea?
"JobHandler" prio=10 tid=0xaec22000 nid=0x51c7 waiting on condition [0xaeb0b000..0xaeb0c030]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for <0xee01fa00> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1925)
        at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:358)
        at MyQueue.pull(MyQueue.java:89)
        at JobHandler.run(JobHandler.java:264)

Similar Messages

Thread Safe Queue Between DLL and EXE

Hello,
We wondered if this architecture would work:
An exe would create a thread safe queue. A dll routine would write to the queue using CmtWriteTSQData. The exe in turn would have an installed callback for the queue for when there are a certain number of items in the queue.
The exe is linked to DLL.
Thank you,
Solved!
Go to Solution.

Hi jharris66,
It sounds like that architecture you suggest should work. However I am not sure what you mean when you say the exe is linked to the DLL. Could you clarify what you mean when you say that?
Thank you!
Rachel M.
Applications Engineer
National Instruments

Are servlets thread safe??

Are servlets thread safe?? if not, then how to make them thread safe.

Hi,
servlets aren't thread-safe; you can make them thread-safe by implementing the interface javax.servlet.SingleThreadModel
From the javadoc:
public interface SingleThreadModel
Ensures that servlets handle only one request at a time. This interface has no methods.
If a servlet implements this interface, you are guaranteed that no two threads will execute concurrently in the servlet's service method. The servlet container can make this guarantee by synchronizing access to a single instance of the servlet, or by maintaining a pool of servlet instances and dispatching each new request to a free servlet.
If a servlet implements this interface, the servlet will be thread safe. However, this interface does not prevent synchronization problems that result from servlets accessing shared resources such as static class variables or classes outside the scope of the servlet.

Discussion: AtomicBuffer - lock-free and thread-safe

Hi,
Since I'm always interested in discussions, I posted the following code for a lock-free, thread-safe buffer implementation.
In this case the buffer stores (Message,Throwable, Level) triplets but that's not the point here.
The interesting parts are addEntry() and getNextSlot(). It's actually the first time, that I tried to make use of the atomic package in a real application.
I'm looking forward to any kind of valuable comment, may it be criticism or praise :)
Cheers, Daniel
* Array-based buffer for storing message-throwable-level triples.
* Uses CAS for lock-free, thread-safe access.
* @author dgloeckner
public class AtomicBuffer {
     private final int mSize;
     private Object[] mMessageBuffer;
     private Throwable[] mThrowableBuffer;
     private Level[] mLevels;
     private AtomicInteger mNextSlot;
     private AtomicInteger mDiscardedMessages;
     public AtomicBuffer(int pSize) {
          super();
          mSize = pSize;
          mMessageBuffer = new Object[pSize];
          mThrowableBuffer = new Throwable[pSize];
          mLevels = new Level[pSize];
          mNextSlot = new AtomicInteger(0);
          mDiscardedMessages = new AtomicInteger(0);
      * Uses CAS for lock-free, thread-safe buffer access.
      * @param pMessage log message
      * @param pThrowable throwable for the message (may be null)
      * @param pLevel log level
     public void addEntry(Object pMessage, Throwable pThrowable, Level pLevel) {
          int lSlot = getNextSlot();
          if (lSlot < mSize) {
               mMessageBuffer[lSlot] = pMessage;
               mLevels[lSlot] = pLevel;
               mThrowableBuffer[lSlot] = pThrowable;
          } else {
               //Buffer is full
               mDiscardedMessages.incrementAndGet();
      * Returns the next free slot.
      * Only increments the next slot counter,
      * if free space is left.
      * @return next free slot
     protected int getNextSlot() {
          int lNextSlot = 0;
          //CAS loop checks if the value read from mNextSlot
          //is smaller than the buffer size.
          //If not, the loop returns.
          //If yes, the loop tries to increment mNextSlot using CAS.
          do {
               lNextSlot = mNextSlot.get();
               if (lNextSlot >= mSize) {
                    break;
          } while (!mNextSlot.compareAndSet(lNextSlot, lNextSlot + 1));
          return lNextSlot;
     public int getSize() {
          return mSize;
     public int getDiscardedMessages() {
          return mDiscardedMessages.get();
     public Level[] getLevels() {
          return mLevels;
     public Object[] getMessages() {
          return mMessageBuffer;
     public Throwable[] getThrowables() {
          return mThrowableBuffer;
      * Returns the number of filled slots.
      * @return number of filled slots
     public int getFilledSlots() {
          return mNextSlot.get();
}

Hi,
OK, so we were talking about different specifications.
If you are sure about that before the time you mentioned only writes, and after that time only read(s) will take place, it's an absolutely good situation.
Sorry, I was very wrong, you're right - some (or most) implementations use hardware CAS. Hey that's a nice feature, isn't it?
I can see that you are using the loop to determine, whether another thread has accessed the counter (or something similar). I think this technique is great,
however, you might end up with a thread waiting for a single buffer space, while the others proceed (although this is not likely).
Anyway, I don't really know why would I want to use a code this complicated.
What about these lines:
public void addEntry(Object pMessage, Throwable pThrowable, Level pLevel) {
int lSlot = mNextSlot.incrementAndGet();
//So this has incremented the value (now remember to instantiate with -1) atomically, fast, with no locking and no loops
//Here I don't really worry about the real value of this int, as I only want to know if my entry fits to the buffer
if (lSlot < mSize) {
mMessageBuffer[lSlot] = pMessage;
mLevels[lSlot] = pLevel;
mThrowableBuffer[lSlot] = pThrowable;
public int getDiscardedMessages(){
return mNextSlot.get()-mSize; //but here I can reuse the information (i.e. the difference), which you would have discarded
}To use this code for general purposes, one could modify it like this:
<code>...
//in the constructor:
fillableSize = pSize;
mSize = pSize + OVERFLOW; //where OVERFLOW is a number that satisfies the conditions in a given environment
</code>...
public boolean isFull(){
return mNextSlot.get() > fillableSize;
//I am sure that there is a thread periodically checking / storing the log itself, of which core should be something like this:
if (currentAtomicBuffer.isFull()){ //or a given time period is exceeded
AtomicBuffer newAtomicBuffer = new AtomicBuffer(BUFFER_SIZE);
logThisToDatabase(lastAtomicBuffer); // log the previous one - there should not be any writer threads
lastAtomicBuffer = currentAtomicBuffer; // this is the preivous one - note that there might be some threads writing to it, but this does not mean any problem
currentAtomicBuffer = newAtomicBuffer; // from now on, work to the new buffer
//for monitoring purposes, you still can use getDiscardedMessages: this will inform you if OVERFLOW is set right. Anyway, it should always return 0.However, one might want to catch the interruptedException (thrown in the thread that empties the buffer) and handle it with a last logThisToDatabase call on lastAtomicBuffer and currentAtomicBuffer as well.
Kind Regards,
Zoltan

SingleThreadModel-static variables thread safe?

Hi..
I have one servlet which implements SingleThreadModel.My servlet contains two static variables .
public class MyServlet extends HttpServlet
implements SingleThreadModel {
private static String firstName="Umar hathab";
private static StringBuffer lastName= new StringBuffer("Abdullah");
I want to know whether this two variables will be thread safe? I know that static vars are shared in JVM..
Please help me..
Thanks in advance..
A.Umar

Hi heyad..
Static variables are shared among the instances.When we create two instances of an object which contains a static variable,both the instances share the same static variable.So there will be data corruption when two instances operate on the static variable at the same time.So I feel static variables are not thread safe.What I want to know is whether static variables are thread-safe when implemented by SingleThreadModel..
A.Umar

Are SocketFactory implementations thread-safe?

Hi!
I'm using a SSLSocketFactory-singleton (SSLSocketFactoryImpl it is I guess) for creating SSLSocket-instances in my application.
I just wondered whether or not I need synchronization especially for using the createSocket(...)-methods in my multi-threaded application, since I can't look in the code due to restrictions. Another question is whether the answer applies to other SocketFactory implementations.
Greetings

georgemc wrote:
JAVAnetic wrote:
georgemc wrote:
Why would you need SocketFactory to be thread-safe anyway?Because, in my multi-threaded application I want to use only one SocketFactory-instance to reduce the overhead of creating one per thread that needs Sockets. So this instance as a shared object used by many threads will need to be synchronized if it is not already thread-safe per se. But all you do with a SocketFactory is ask it for sockets. What issues do you think you'll face with multi-threaded requests for new instances of something? Just because you've got multi-threaded code, doesn't mean everything you use has to be synchronized.I know, but since I don't know what the factory-implementation actually does creating those instances I think it is always worth asking, if I have to synchronize even if it may be true that the design of (the) factory-implementation(s) is in fact thread-safe, which no one until now could tell me for sure.

Are Queues thread safe

Hi all,
Are Queues thread safe i.e. are enqueue, dequeue etc atomic?
I'm looking to use Queues to transfer object states between concurrent loops, but am concerned whether I need to protect access via a semaphore.
Thanks
Phill
Solved!
Go to Solution.

Hi all,
I've been discussing transfering the state of an object between concurrent loops here and was hoping to use a single element queue.
I'm still a little worried about a context switch while I'm updating the status of the object in the area highlighted.
Would I still need a semaphore lock to ensure the data integrity of the queue between the flush and enqueue in case the data loop sneaks in and tries to read the queue?

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,
Steve

stevephe 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

Is Observable thread safe?

hello
im trying to write a programme that uses observer observable.
I have an observing class that may be observing 3 or 4 instances of an observable class. each of these observable classes runs a separate thread.
Am i right to think that when an observervable instance notifiesAll() it will be added to a queue of notifications for each observer?

Observable itself is thread-safe, but it does not enforce any threading behavior on the Observer. so, your Observer implementation must be thread-safe.

Is Executor thread-safe

Hello,
Suppose you have an Executor to execute tasks (one of the standard implementations provided by the JDK).
Is there any risk if you have multiple threads that use the executor to submit or execute tasks?.
In other words: Is Executor thread-safe?
I'm not talking about the working threads that execute the tasks.
I'm talking about the threads that send the tasks to execution.
Thank you.

JoseLuis wrote:
can you please tell me where can I find that kind of facts, because I could not find it in the javadoc.Well, it isn't a requirement for ExecutorServices, but it how the implementations provided by the java.util.concurrent package operate. That fact is stated in the API for ThreadPoolExecutor in several places:
In the class description:
Queuing
Any BlockingQueue may be used to transfer and hold submitted tasks.Then, all the Constructors that take work queues only take BlockingQueues, and the getQueue() method returns a BlockingQueue.
Finally, there are only 2 implementations of the ExecutorService provided, ThreadPoolExecutor, and ScheduledThreadPoolExecutor, which subclasses ExecutorService (and does not indicate different rules for Queues).
>
if you can tell me about a book or official document it would be great.
thanx again

SortedSet thread-safe howto?

Hello,
i m trying to acces SortedSet with multiple thread, but i can't
here is my code :
public class Test {
static SortedSet queue = Collections.synchronizedSortedSet((SortedSet) new TreeSet());
static Vector v = new Vector();
public static Vector getV() { return v;}
public static SortedSet getQueue () {
return queue;
public static void main(String[] args) throws Exception {
launchFrame();
for (int i=0; i<2; i++) {
new SimpleThread2("thread"+i).start();
public static void end() {
System.out.println(v.size()+" lalala "+queue.size());
class SimpleThread2 extends Thread {
int j = 0;
public SimpleThread2(String str) {
super(str);
public void run() {
for (int i = 0; i < 10; i++) {
try {
SortedSet s = Test.getQueue();
synchronized (s) {
s.add(new String(""+i));
Test.getV().add(""+i);
} catch (Exception ex) {ex.printStackTrace();}
Test.end();
here is my result :
10 lalala 10
20 lalala 10
as u can see Vector is thread safe but SortedSet not....

That has nothing to do with Thread-safe or not. A Set be it sorted or not always only contains at most one reference to a specific Object as long as equals() and compareTo() are implemented properly.
In the second run you add identical Strings to both the SortedSet and the Vector. In the SortedSet, they replace the old entries and in the Vector, they are appended as the Vector is a List and allows multiple identical entries.

LinkedBlockingQueue is thread safe?

Hi all,
maybe this is a silly question, but:
is LinkedBlockingQueue thread safe?
I've read all api docs and tutorials, but it's not explicitly said that this class is thread safe (e.g. for ConcurrentLinkedQueue it's explicitly said).
If yes, than all classes in concurrent package are thread safe?
Many thanks in advance,
Paul

[url=http://java.sun.com/j2se/1.5.0/docs/api/java/util
/concurrent/BlockingQueue.html]BlockingQueue
API
BlockingQueue implementations are thread-safe. All
queuing methods achieve their effects atomically
using internal locks or other forms of concurrency
control. However, the bulk Collection operations
addAll, containsAll, retainAll and removeAll are not
necessarily performed atomically unless specified
otherwise in an implementation. So it is possible,
for example, for addAll(c) to fail (throwing an
exception) after adding only some of the elements in
c.
I got on the phone and forgot to press the post button.

Is addBatch/executeBatch thread safe

Hi,
I want to make a prepared statement that is shared between two threads.
one thread will perform the addBatch and the other thread will periodically executeBatch.
will this work safely or it will cause problems with concurrency?

I tried to use queuing using a Vector but in time the
queue gets bigger, and eventually gives out of
memory, also causes delay on insertion of data.Batch will suffer from all the same problems as well as some others. Where do you think the data in the batch is stored prior to transmission?
Please don't take this the wrong way, but I don't think you're competent to do this. Use a single threaded approach.
I already tried to use the approach I am asking about
in the first post, it works fine without delay or
memory issuesYou merely implemented the vector approach incorrectly. Or possibly you weren't correctly batching your transmissions.
, But I am still not sure if a
concurrency issue will rise in the future.It will.
so are they thread safe or not?Nothing to do with JDBC is threadsafe except for acquisition of a connection. It's your responsibility to ensure thread safety, and I don't believe you're likely to get this right if you weren't aware of that in the first place.
It sounds like an insult, I know, but it's not something anyone is born knowing.

How can I use a Selector in a thread safe way?

Hello,
I'm using a server socket with a java.nio.channels.Selector contemporarily by 3 different threads (this number may change in the future).
From the javadoc: Selectors are themselves safe for use by multiple concurrent threads; their key sets, however, are not.
Following this advise, I wrote code in this way:
         List keys = new LinkedList(); //private key list for each thread
         while (true) {
          keys.clear();
          synchronized(selector) {
              int num = selector.select();
              if (num == 0)
               continue;
              Set selectedKeys = selector.selectedKeys();
              //I expected this code to produce disjoint key sets on each thread...
              keys.addAll(selectedKeys);
              selectedKeys.clear();
          Iterator it = keys.iterator();
          while (it.hasNext()) {
              SelectionKey key = (SelectionKey) it.next();
              if ((key.readyOps() & SelectionKey.OP_ACCEPT) == SelectionKey.OP_ACCEPT) {
               Socket s = serverSocket.accept();
               SocketChannel sc = s.getChannel();
               sc.configureBlocking( false );
               sc.register( selector, SelectionKey.OP_READ );
              } else if ((key.readyOps() & SelectionKey.OP_READ) == SelectionKey.OP_READ) {
//.....Unfortunately synchronizing on the selector didn't have the effect I expected. When another thread select()s, it sees the same key list as the other thread that select()ed previously. When control arrives to serverSocket.accept(), one thread goes ahead and the other two catch an IllegalBlockingModeException.
I'm not willing to handle this exception, the right thing to do is giving disjoint key sets to each thread. How can I achieve this goal?
Thanks in advance

A single thread won't be enough cause after reading data from the socket I do some processing on it that may take long.So despatch that processing to a separate thread.
Most of this processing is I/O boundI/O bound on the socket? or something else? If it's I/O bound on the socket that's even more of a reason to use a single thread.
Anyway I think I'll use a single thread with the selector, put incoming data in a queue and let other 2 or 3 threads read from it.Precisely. Ditto outbound data.
Thanks for your replies. But I'm still curious: why is a selector thread safe if it can't be used with multiple threads because of it's semantics?It can, but there are synchronization issues to overcome (with Selector.wakeup()), and generally the cost of solving these is much higher than the cost of a single-threaded selector solution with worker threads for the application processing.

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.

Thread safe Queue implementation

Similar Messages

Maybe you are looking for