Native pthread mutex on 1:1 threading model

Hi,
I wanted to verify with the experts that it is safe to use a native mutex in JNI instead of
MonitorEnter/MonitorExit on all JREs that map a java thread to a native thread in a
1:1 fashion. Why do this? Because MonitorEnter/Exit pair takes 500 nanos which
is way to slow for my JNI component. Of course, on threading models that
are not 1:1 I am definitely not safe(?).
By the way, does anyone know if the SUN hotspot for windows is a 1:1 threading model.
I know that it is for Linux.
Andy

i know that it's old but some other ppl can found it.
actually i'm using a pthread_mutex_lock on linux/unix and WaitForSingleObject on windows. see, i don't create threads inside the jni glue, but i create mutexes.
it seems to work well, but for some unknow reason it leads to deadlocks on certain unices.
right now i'm going to change my implementations for MonitorEnter/Exit and GetPrimitiveArrayCritical.

Similar Messages

Xsql servlet threading model?

does anybody know the threading model supporting by the xsql servlet? from my testing, it appears that it only supports single threaded.
environment: nt 4.0, svcpack 5/iis/servlet exec 2.2/jdk 1.1.8/xsql servlet 0.9.6
any help/info appreciated.
thanks
michael lasmanis

steve,
here are the java vm settings from servlet exec. all the other settings are in line with the install instructions.
VM Settings
Java VM: 1.1.8 from Sun Microsystems Inc.
JITC: symcjit
Host: Windows NT 4.0 on x86
Native Stack Size: 128K Bytes
Java Stack Size: 400K Bytes
Minimum Heap Size: 1024K Bytes
Maximum Heap Size: 524288K Bytes
Verbose GC: Disabled
Verbose: Disabled
JITC: Enabled
Class GC: Enabled
Async GC: Enabled
Verify: Remote
Java VM: Sun Classic
null

Threading model: Linux, MacOSX, Win32

Hi,
I've been searching these forums for topics regarding Java threading models for the three operating systems for which we build Java applications: Linux, MacOSX and Windows. So far, I've only got a clear picture on the Win32 environment. It uses native threads, which I'm told is best for performance.
My question is: what threading models do the virtual machines for Linux and MacOSX support these days? Are they working with socalled "green threads" or do they use the more powerful native threads as well? I can't seem to find any recent posts with information on this subject.
Thanks in advance

Here is an article that you might find interesting:
Programming Java threads in the real world
http://www.javaworld.com/javaworld/jw-09-1998/jw-09-threads.html
Jesper

Alternative Threading Model in Solaris 8?

I haven't been able to get to any Solaris 8 docs yet, but I've been hearing about his alternative threading model available in Solaris 8. Can someone explain it to me?

I know this question was posted a while ago, but this info may be of help.
As well as improved real-time support for threads, Solaris 8 has an extra set of thread libraries under /usr/lib/lwp.
They are designed to be direct replacements for the standard libraries; you can pick them up by linking against them or using LD_LIBRARY_PATH.
This new one-level libthread is a library that implements all of the POSIX and Solaris threads interfaces using a one-level threading model, where threads are one-to-one with lightweight processes (LWPs), rather than the two-level model that is used in the standard libthread implementation, where user-level threads are multiplexed over possibly fewer LWPs.
It has been found in tests that some applications perform much better with the new library. However, more kernel resources are consumed.
Hope that helps.
Ralph
SUN DTS

Single Threaded Model JSP- Servlet

Servelts can be set to have thread safe access (Single thread model). However, when a JSP is converted in to a servlet, is the servlet tagged as to use the single thread model?

As of JSP specification 1.2 the default value for the "isThreadSafe" attribute of the page directive is true indicating that the container can direct multiple requests to the page simultaneously. If this value is set to false then the requests will be sent one at a time.
Good Luck!
Eshwar Rao
Developer Technical Support
Sun microsystems inc
http://www.sun.com/developers/support

Struts Action threading model bottleneck

Hi,
Struts Action classes are only instantiated once. Then the controller servlet routes all perform/execute calls through the single instantiated Action class. Does this create a performance bottleneck? Any insights would be helpful.
Thanks

It's more performant, since it doesn't need to create new objects for each request. You just need to write your code in a thread-safe manner (watch the instance variable!).
Cheers

BPEL Threading Model

I have three BPEL Processes: BPEL1, BPEL2 and BPEL3 invoking each other in a synchronous fashion as shown below:
Synchronous flow - BPEL1 -> BPEL2 -> BPEL3
I have a java web service which sends in the request to the BPEL1. I would like to increase the no of threads to handle more requests from the Java web service. I looked up four parameters that can be tuned:
Dispatcher Invoke Threads
Dispatcher Engine Threads
Dispatcher System Threads
Dispatcher Maximum Request Depth
As per my understanding Dispatcher Invoke Threads comes into the picture when a synchronous transaction is involved. The question I have is:
Is the value of 20 per instance of BPEL Process or per synchronous transaction? With the above flow stated, BPEL1 invoking BPEL2, BPEL2 invoking BPEL3 and response flow from BPEL3 to BPEL2 and BPEL2 to BPEL1, all being synchronous calls, is this parameter for every instance of BPEL1 alone (per synchronous transaction) or per BPEL instance of BPEL1,BPEL2 and BPEL3?*

No, "Dispatcher Invoke Threads" come into play with async (oneway / possible callbacks). This setting controls the threadpool size to create new process instances, after the originator thread saved the instance data and returned.
Engine threads handle callbacks and expirations
System threads are cleanup threads

Request for discussion about pthread's mutexes

Hello,
A case looks simple. Two threads can communicate with device using ethernet interface. Because protocol's manners only one can use the channel. To provide exclusive execution I used a pthread mutex.
An error is situation when thread A waits on mutex (thread B owns it), but when thread B releases it, thread A still sleeps. After a tick thread B again trying to lock mutex and succeed. Thread A sleeps on mutex until thread B calls function pthread_join with thread A id. Probability of error increases with speed of device. If more packets in second are sent and received, the error almost always happen.
I spent many hours with e.g. truss and I am almost sure that it isn't implementation problem. I haven't ideas what do I wrong.
The error not depend on what type mutexes are (default or recursive), libs (pthread, thread or alternative thread), if thread is bound with lwp or unbound.
Threads: A and B are created with the same way, i.e. with the same priority and attributes.
I use Solaris 8 with recommended patch and gcc.
Any ideas will be welcome.
Thanks
Marcin

I don't like the idea of using pthread_join in thread
B to wait for thread A.
Please read the
"Multithreaded Programming Guide"
http://docs.sun.com/db/doc/806-6867
and
"Multithreading in the Solaris Operating Environment"
http://wwws.sun.com/software/whitepapers/solaris9/multithread.pdf
They are must for all Solaris mt software developers.

Cannot get bitmap from native DLL from multi threaded Java app.

I have a native DLL that gives me a HBITMAP (Windows handle to bitmap). I have made a JNI wrapper for this that gives me a BufferedImage back. The native code simple gets the actual bitmap for the handle, converts the RGB byte triplets to RGB ints, puts this in a jintArray and creates a BufferedImage.
This all works fine within a single Java thread. If I do this multi threaded (thread 1 calls the native function and several seconds later, thread 2 calls the native function) I keep getting the last image of the first thread. Can enyone help me out?
I know that this is probably a question for MSDN but I just know that they will tell me its a JNI question.
The native code:
JNIEXPORT jobject JNICALL Java_somenamespace_getPicture
(JNIEnv *env, jclass cl, jstring serialNumber)
jobject jImage;
jclass jImageClass;
jmethodID jMethod;
jfieldID jField;
jintArray rgbArray;
char *str;
char *charArray;
int *intArray;
int w, h, index, type;
HBITMAP hbmp;
BITMAP bmp;
str = (char*)((*env)->GetStringUTFChars(env, serialNumber, NULL));
// Gets the HBITMAP handle from the native DLL. The first argument is to select the device, based on serial number.
getPicture(str, &hbmp);
(*env)->ReleaseStringUTFChars(env, serialNumber, str);
// Get the BITMAP for the HBITMAP
GetObject(hbmp, sizeof(BITMAP), &bmp);
// Create my BufferedImage
jImageClass = (*env)->FindClass(env, "java/awt/image/BufferedImage");
jMethod = (*env)->GetMethodID(env, jImageClass, "<init>", "(III)V");
jField = (*env)->GetStaticFieldID(env, jImageClass, "TYPE_INT_RGB", "I");
type = (*env)->GetStaticIntField(env, jImageClass, jField);
jImage = (*env)->NewObject(env, jImageClass, jMethod, bmp.bmWidth, bmp.bmHeight, type);
// Get the RGB byte triplets of the BITMAP
charArray = (char *)malloc(sizeof(char) * bmp.bmHeight * bmp.bmWidth * 3);
GetBitmapBits(hbmp, sizeof(char) * bmp.bmHeight * bmp.bmWidth * 3, charArray);
// Allocate space to store the RGB ints and convert the RGB byte triplets to RGB ints
intArray = (int *)malloc(sizeof(int) * bmp.bmHeight * bmp.bmWidth);
index = 0;
for (h = 0; h < bmp.bmHeight; ++h)
for (w = 0; w < bmp.bmWidth; ++w)
int b = *(charArray + index * 3) & 0xFF;
int g = *(charArray + index * 3 + 1) & 0xFF;
int r = *(charArray + index * 3 + 2) & 0xFF;
*(intArray + index) = 0xFF000000 | (r << 16) | (g << 8) | b;
++index;
// Create a jintArray for the C RGB ints
rgbArray = (*env)->NewIntArray(env, bmp.bmHeight * bmp.bmWidth);
(*env)->SetIntArrayRegion(env, rgbArray, 0, bmp.bmHeight * bmp.bmWidth, (jint*)intArray);
// Use BufferedImage.setRGB() to fill the image
jMethod = (*env)->GetMethodID(env, jImageClass, "setRGB", "(IIII[III)V");
(*env)->CallVoidMethod(env, jImage, jMethod,
0, // int startX
0, // int startY
bmp.bmWidth, // int width
bmp.bmHeight, // int height
rgbArray, // int[] rgbArray
0, // int offset
bmp.bmWidth); // int scansize
// Free stuff
(*env)->DeleteLocalRef(env, rgbArray);
free(charArray);
free(intArray);
return jImage;
}I already tried working with native HDCs (GetDC, CreateCompatibleBitmap, SelectObject, GetDIBits, ...) but this just complicates stuff and gives me the same result.

Have you verified what the "native DLL" gives you back on the second call?The HBITMAP handle returned is the same each call (no matter which thread). The actual BITMAP associated with this handle is only updated in the first thread.
How are you determining that the image is the same?If I point the camera (I don't get a stream, I just get individual images) to a moving scene, I get different images for each call from within the first thread. The second thread only gets the latest image from the first thread. There is no concurrency of the threads and all methods are synchronized.
Specifically did you verify that the problem is not that your test code itself is using the same instance?Yes, I tested the native side as well as the Java side. The BufferedImage is always an exact copy of the native BITMAP.
Try printing out the hash for each instance.I have written the image to a file in the native code itself to eliminate anything related to the mechanism of returning the BufferedImage. This had the same result.
The return values of all native calls all indicate successful calls.
I am suspecting the native side of creating a second graphical context for the second thread while it keeps refering to the first context.
(I will start a thread on the MSDN as well and will post here if anything turns up.)

Performance problem - mutexes with multi-cpu machine

Hi!
My company is developing multi-threaded server program for
multi-cpu machine which communicates with Oracle database on separate
machine. We use Solaris 7, Workshop 5 CC and pthreads API.
We tested our program on 4 CPU E4500 with 2 CPU E420 Oracle server.
We upgraded E4500 from 4 to 8 CPU and to our surprise instead of
performance improvement we got performance degradation ( 8 CPU runs
about 5% slower than 4 CPU ).
After a long investigation we found out that under stress load most of the
time our performs lwpmutex related operation.
With truss -c statistics was 160 secs in mutex operations and
about 2 secs was read/write in oracle client side library.
Here is output of truss for example:
19989 29075/5: 374.0468 0.0080 lwp_mutex_lock(0x7F2F3F60 = 0
19990 29075/31: 374.0466 0.0006 lwp_mutex_wakeup(0x7F2F3F60) = 0
19991 29075/5: 374.0474 0.0006 lwp_mutex_wakeup(0x7F2F3F60) = 0
19992 29075/30: 374.0474 0.0071 lwp_mutex_lock(0x7F2F3F60) = 0
19993 29075/30: 374.0484 0.0010 lwp_mutex_wakeup(0x7F2F3F60) = 0
19994 29075/31: 374.0483 0.0017 lwp_mutex_lock(0x7F2F3F60) = 0
19995 29075/5: 374.0492 0.0018 lwp_mutex_lock(0x7F2F3F60) = 0
19996 29075/31: 374.0491 0.0008 lwp_mutex_wakeup(0x7F2F3F60) = 0
19997 29075/5: 374.0499 0.0007 lwp_mutex_wakeup(0x7F2F3F60) = 0
19998 29075/30: 374.0499 0.0015 lwp_mutex_lock(0x7F2F3F60) = 0
19999 29075/5: 374.0507 0.0008 lwp_mutex_lock(0x7F2F3F60) = 0
20000 29075/30: 374.0507 0.0008 lwp_mutex_wakeup(0x7F2F3F60) = 0
20001 29075/5: 374.0535 0.0028 lwp_mutex_wakeup(0x7F2F3F60) = 0
20002 29075/30: 374.0537 0.0030 lwp_mutex_wakeup(0x7F2F3F60) = 0
20003 29075/31: 374.0537 0.0046 lwp_mutex_lock(0x7F2F3F60) = 0
20004 29075/5: 374.0547 0.0012 lwp_mutex_lock(0x7F2F3F60) = 0
20005 29075/31: 374.0546 0.0009 lwp_mutex_wakeup(0x7F2F3F60) = 0
20006 29075/5: 374.0554 0.0007 lwp_mutex_wakeup(0x7F2F3F60) = 0
20007 29075/30: 374.0557 0.0020 lwp_mutex_lock(0x7F2F3F60) = 0
20008 29075/31: 374.0555 0.0009 lwp_mutex_wakeup(0x7F2F3F60) = 0
20009 29075/5: 374.0564 0.0010 lwp_mutex_lock(0x7F2F3F60) = 0
20010 29075/30: 374.0564 0.0007 lwp_mutex_wakeup(0x7F2F3F60) = 0
20011 29075/5: 374.0572 0.0008 lwp_mutex_wakeup(0x7F2F3F60) = 0
20012 29075/28: 374.0574 0.0170 lwp_mutex_lock(0x7F2F3F60) = 0
20013 29075/31: 374.0575 0.0020 lwp_mutex_wake(0x7F2F3F60) = 0
We have a several question:
1. We always get the same mutex address : 0x7F2F3F60 even with different
binaries. It looks that all threads wait on one and magic
mutex. Why?
2. We read in article on unixinsider.com that on Solaris when mutex is
unlocked all the threads waiting on this mutex are waked up. It also looks so
from truss output. What is solution for this problem? unixinsider.com
recommends native Solaris read-write lock with all threads as writers?
Is there any other solution? Should in improve performance?
3. We heard that Solaris 8 has better pthreads implementation using a
one-level threading model, where threads are one-to-one with
lwp, rather than the two-level model that is used in the
standard libthread implementation, where user-level threads are
multiplexed over possibly fewer lwps. Are mutexes in this library
behave in "Solaris 7" way or do it put thread to sleep when it unlocks
the mutex? Is it possible to use this library on Solaris 7?
4. Is there plug - in solution like mtmalloc or hoard for new/delete that change
pthread mutexes?
Thank you in advance for your help,
Alexander Indenbaum

<pre>
Hi!
My company is developing multi-threaded server program for
multi-cpu machine which communicates with Oracle database on separate
machine. We use Solaris 7, Workshop 5 CC and pthreads API.
We tested our program on 4 CPU E4500 with 2 CPU E420 Oracle server.
We upgraded E4500 from 4 to 8 CPU and to our surprise instead of
performance improvement we got performance degradation ( 8 CPU runs
about 5% slower than 4 CPU ).
After a long investigation we found out that under stress load most of the
time our performs lwpmutex related operation.
With truss -c statistics was 160 secs in mutex operations and
about 2 secs was read/write in oracle client side library.
Here is output of truss for example:
19989 29075/5: 374.0468 0.0080 lwp_mutex_lock(0x7F2F3F60) = 0
19990 29075/31: 374.0466 0.0006 lwp_mutex_wakeup(0x7F2F3F60) = 0
19991 29075/5: 374.0474 0.0006 lwp_mutex_wakeup(0x7F2F3F60) = 0
19992 29075/30: 374.0474 0.0071 lwp_mutex_lock(0x7F2F3F60) = 0
19993 29075/30: 374.0484 0.0010 lwp_mutex_wakeup(0x7F2F3F60) = 0
19994 29075/31: 374.0483 0.0017 lwp_mutex_lock(0x7F2F3F60) = 0
19995 29075/5: 374.0492 0.0018 lwp_mutex_lock(0x7F2F3F60) = 0
19996 29075/31: 374.0491 0.0008 lwp_mutex_wakeup(0x7F2F3F60) = 0
19997 29075/5: 374.0499 0.0007 lwp_mutex_wakeup(0x7F2F3F60) = 0
19998 29075/30: 374.0499 0.0015 lwp_mutex_lock(0x7F2F3F60) = 0
19999 29075/5: 374.0507 0.0008 lwp_mutex_lock(0x7F2F3F60) = 0
20000 29075/30: 374.0507 0.0008 lwp_mutex_wakeup(0x7F2F3F60) = 0
20001 29075/5: 374.0535 0.0028 lwp_mutex_wakeup(0x7F2F3F60) = 0
20002 29075/30: 374.0537 0.0030 lwp_mutex_wakeup(0x7F2F3F60) = 0
20003 29075/31: 374.0537 0.0046 lwp_mutex_lock(0x7F2F3F60) = 0
20004 29075/5: 374.0547 0.0012 lwp_mutex_lock(0x7F2F3F60) = 0
20005 29075/31: 374.0546 0.0009 lwp_mutex_wakeup(0x7F2F3F60) = 0
20006 29075/5: 374.0554 0.0007 lwp_mutex_wakeup(0x7F2F3F60) = 0
20007 29075/30: 374.0557 0.0020 lwp_mutex_lock(0x7F2F3F60) = 0
20008 29075/31: 374.0555 0.0009 lwp_mutex_wakeup(0x7F2F3F60) = 0
20009 29075/5: 374.0564 0.0010 lwp_mutex_lock(0x7F2F3F60) = 0
20010 29075/30: 374.0564 0.0007 lwp_mutex_wakeup(0x7F2F3F60) = 0
20011 29075/5: 374.0572 0.0008 lwp_mutex_wakeup(0x7F2F3F60) = 0
20012 29075/28: 374.0574 0.0170 lwp_mutex_lock(0x7F2F3F60) = 0
20013 29075/31: 374.0575 0.0020 lwp_mutex_wakeup(0x7F2F3F60) = 0
We have a several question:
1. We always get the same mutex address : 0x7F2F3F60 even with different
binaries. It looks that all threads wait on one and magic
mutex. Why?
2. We read in article on unixinsider.com that on Solaris when mutex is
unlocked all the threads waiting on this mutex are waked up. It also looks so
from truss output. What is solution for this problem? unixinsider.com
recommends native Solaris read-write lock with all threads as writers?
Is there any other solution? Should in improve performance?
3. We heard that Solaris 8 has better pthreads implementation using a
one-level threading model, where threads are one-to-one with
lwp, rather than the two-level model that is used in the
standard libthread implementation, where user-level threads are
multiplexed over possibly fewer lwps. Are mutexes in this library
behave in "Solaris 7" way or do it put thread to sleep when it unlocks
the mutex? Is it possible to use this library on Solaris 7?
4. Is there plug - in solution like mtmalloc or hoard for new/delete that change
pthread mutexes?
Thank you in advance for your help,
Alexander Indenbaum
</pre>

"Portable" way to do message passing between threads?

(I posted this on the Apple Developer Forums already, but since that forum is only accessible to registered and paid iPhone developers, I thought it would be nice to put it here as well so as to get some more potential eyeballs on it. I apologize if this kind of "cross-posting" is not kosher/is frowned upon around here.)
Hey everybody,
"Long-time listener, first-time caller," heh.
I've been working for the past 2-3 months on my very first iPhone app. Actually, what I've been working on is a framework that I plan to use in an iPhone app of my own but which I am also trying to write for the "lowest-common-denominator" so that I (and others) can use it in other apps written for both Mac and iPhone.
Not only is this my first time writing an iPhone app, it is my first time writing for any Apple platform. In fact, it is my first time using Objective-C, period. I cannot stress this enough: I am a "n00b." So go easy on me. I also have not worked with threading before this, either, on any platform, so the learning curve for me here is rather significant, I'm afraid. I am NOT afraid of either taking the time to learn something properly OR of rolling up my shirtsleeves and working. However, on account of my experiences so far, I am finding myself (not to flame or anything!) quickly becoming frustrated by and disillusioned with not so much Objective-C itself, but the Foundation frameworks.
So with that said, read on, if you dare...
The basic idea behind my project is that the framework I am writing will present an API to developers which will allow them to write client apps that interact with a particular network appliance or network-aware embedded system. I already have my basic set of classes up and functioning, and the framework works to my satisfaction both on MacOS and iPhoneOS. The platforms I am targeting are MacOS X Tiger 10.4 and later, and iPhoneOS, and up until this point, I've managed to keep a codebase that works on all of the above.
What I wanted to do next was add some multithreaded goodness to the mix. (Woe is me.) I have asynchronous network socket I/O working within the main thread, and it, in fact, works a treat. In my test app on the phone, I've managed to keep the UI nice and responsive by using the main thread's runloop efficiently. But even though TCP async I/O works fine within the main thread, I want to be able to split out and offload the processing of any data received by the app from the appliance to its own thread. (It is possible, and even desirable, for an application using this framework to be connected to multiple appliances simultaneously.)
My idea, in order to try to keep things as simple and as clean as possible, was to implement a wrapper class that presented my other main class as an "actor." So, rather than instantiating my main class, one would create an instance of the wrapper class which would in turn control a single instance of my main class and spawn its own thread that the network connection and all data processing for that particular connection would run within.
(I hope I'm making sense so far...)
Out of the gate, writing a subclass of NSThread sounds like the logical design choice for an "actor-type" thread, but because I was trying to maintain Tiger compatibility, I stuck with +detachNewThreadSelector:etc.
Once I decided to pursue the actor model, though, the main problem presented itself: how to best pass messages between the main thread and all of the "actor" threads that might be spawned?
I stumbled upon -performSelector:onThread:withObject:, and knew instantly that this was exactly what I was looking for. Unfortunately, it doesn't exist on Tiger; only its much more limited little brother -performSelectorOnMainThread:withObject: does. So I kept looking.
All of the pre-Leopard documentation, tutorials, and sample code that I read indicated that to pass messages between threads, I needed to basically pretend that the threads were separate processes and use the expensive Distributed Objects mechanism to get messages back and forth. Unfortunately, even if that WAS a desirable option, iPhoneOS does not have any support for DO! Grrr...
Finally, I thought I found the answer when I ran into a third-party solution: the InterThreadMessaging library from Toby Paterson (available @ http://homepage.mac.com/djv/FileSharing3.html). In this library, the author basically implemented his own version of -performSelector:onThread:withObject: called -performSelector:withObject:inThread:. Sounds close enough, right? And actually, it is pretty darn close. It's made to do exactly what it sounds like, and it does it in a platform-neutral way that works on pre-Leopard systems as well as iPhoneOS, using Mach ports instead of DO.
(...wellll, ALMOST. I discovered after I built a small test app around it that it actually isn't "iPhone-clean." The author used an NSMapTable struct and the NSMap*() functions, which don't exist in iPhoneOS, and he also implemented the handlePortMessage delegate method, but although iPhoneOS has NSPort, it DOESN'T have NSPortMessage. GAAARGH. So I took the time to replace the NSMapTable stuff with NSValue-wrapped objects inside of an NSMutableDictionary, and replaced the handlePortMessage method implementation with a handleMachMessage method, which took some doing because I had to figure out the structure of a Mach message, NO thanks to ANY of the available documentation...)
Once I started using it, though, I quickly discovered that this implementation wasn't up to snuff. My "actor" class and my main thread will be passing a ton of messages to each other constantly whenever there is network activity, and with InterThreadMessaging, I found that whenever activity started to ramp up, it would collapse on itself. This mostly took the form of deadlocks. I found a note that someone else wrote after experiencing something similar with this library (quoted from DustinVoss @ http://www.cocoadev.com/index.pl?InterThreadMessaging):
"It is possible to deadlock this library if thread A posts a notification on thread B, and the notification on B causes a selector or notification to be posted on thread A. Possibly under other circumstances. I have resolved this in my own code by creating an inter-thread communication lock. When a thread wants to communicate, it tries the lock to see if another thread is already using the InterThreadMessaging library, and if it can't get the lock, it posts a message to its own run-loop to try again later. This is not a good solution, but it seems to work well enough."
So I tried implementing what he described using a global NSLock, and it did help with some of the deadlocks. But not all. I believe the culprit here is the Mach ports system itself (from the NSPortMessage documentation for -sendBeforeDate:):
"If the message cannot be sent immediately, the sending thread blocks until either the message is sent or aDate is reached. Sent messages are queued to minimize blocking, but failure can occur if multiple messages are sent to a port faster than the portís owner can receive them, causing the queue to fill up."
InterThreadMessaging in fact calls -sendBeforeDate: and exposes the deadline option, so I tried setting a really short time-to-live on the Mach messages and then intercepted any NSPortTimeoutExceptions that were thrown; upon catching said exceptions, I would then re-queue up the message to be sent again. It worked, but Performance. Was. A. Dog. At least the message queue wouldn't be full indefinitely anymore, causing the main thread to block, but during the whole time that these messages were expiring because the queue was full and then being re-queued, either the main thread was trying to send more messages or the actor thread was trying to send more messages. And as far as I can tell, the Mach ports queue is global (at the very least, there is seemingly only one per process). The message would get through with this model...eventually.
JUST IN CASE the problem happened to be something I screwed up as I was rewriting portions of the InterThreadMessaging library so that it would compile and work on the iPhone SDK, I substituted in the original version of the library in my Mac test app to see if any of these problems became non-issues. I found that both versions of the library -- mine and the original -- performed identically. So that wasn't it.
Finally, in frustration I said, "screw it, I'm going to try it the Leopard way," and replaced all of the method calls I was making to InterThreadMessaging's -performSelector:withObject:inThread: with calls to Foundation's native -performSelector:onThread:withObject: instead, changing nothing else within my code in the process. And wouldn't you know: IT WORKED GREAT. Performance was (and is) fantastic, about on-par with the non-threaded version when only dealing with a single connection/instance of my class.
So, in the end, I was able to do nothing to salvage the InterThreadMessaging implementation of cross-thread method calling, and as far as I can tell, I'm out of (good) options. And thus my mind is filled with questions:
How is the Leopard -performSelector:onThread: method implemented? I'm guessing not using Mach ports, given that I didn't have the same blocking & deadlocking problems I had with InterThreadMessaging. Is it possible to re-implement this Leopard+ method in a similar manner as a category to NSObject under Tiger? Or is it possible, perhaps, to increase the size of the Mach ports queue so that InterThreadMessaging works at a sane level of performance? Or -- I'm getting desperate here -- is there any way that I could trick -performSelectorOnMainThread: to target a different thread instead? (I am assuming here that -performSelectorOnMainThread is implemented under-the-hood much like the new -performSelector:onThread: is implemented, but with a hard-coded NSThread pointer built-in to the code, and that the new method just exposes a more flexible interface to what is basically the same code. I'm probably wrong...) Is there another third-party library out there that I've missed that fits my requirements for being able to do message-passing between threads in an efficient and portable manner?
I refuse to believe that there is no way for me to maintain compatibility with all of the platforms I wish to support without having to resort to making preprocessor #ifdef spaghetti out of my code. And there SURELY has to be a better way of doing cross-thread message passing in Tiger without using Distributed Objects, for Pete's sake! Is this really how people did it for years-on-end since the dawn of NeXT up until the advent of Leopard? And if there really, genuinely wasn't another alternative, then what is up with the lack of DO in iPhoneOS?? Does Apple seriously intend for developers who have good, solid, tested and working code to just chuck it all and start over? What if there was some aspect of DO that previous implementations relied upon that cannot be recreated with simple -performSelector:onThread: calls? (I don't know what those aspects would be...just a hypothetical.) I mean, I can understand needing to write new stuff from scratch for your UI given how radically different the interface is between the Mac and iPhone, but having to reimplement back-end guts such as something as elemental as threads...really?!
I do laud the inclusion of the new method in Leopard as well as the new ability to subclass NSThread itself. But for those of us that need to support Tiger for one reason or another, some of these restrictions and omissions within iPhoneOS seem like rather pointless (and frustrating) roadblocks.
As I hope is obvious here, I have tried to do my homework before throwing up my hands and pestering y'all. If you have the patience to deal with me, please tell me what I am missing.
Thanks for taking the time to read,
-- Nathan

Thanks again for your patience. Comments below.
etresoft wrote:
It is pretty unusual that anyone would want to call perfomrSelector on any thread other than the main thread.
What I described in my original post was not a worker thread, but an "actor."
It is hard for me to answer this question because there are so many options available to do "message passing". The fact that you think there are so few tells me that you really aren't sure what you need to use.
I didn't say there were few options for message passing. I said there were few options for message passing that fit my criteria, which are that any potential solutions should both A) work efficiently and with good performance, and B) be available both pre-Leopard AND on the iPhone. -performSelector: ain't available before Leopard. Distributed Objects is overkill. Kernel Mach messages apparently have a high overhead, too, as my experience with the third-party library I wrote about in my original message shows.
...consider notifications.
I thought notifications couldn't be posted across threads, either. How do I post a notification to another thread's default notification center or notification queue from a different thread?
The notification center is owned by the process. Each run loop can listen for just the notifications it wants. You don't "pass" or "send" notifications, you run then up the flagpole for all to see.
I am aware of how to use notifications. The documentation for NSNotificationCenter clearly states that "In a multithreaded application, notifications are always delivered in the thread in which the notification was posted, which may not be the same thread in which an observer registered itself."
So, again, I don't see how one thread can post a notification in such a way that the observer's registered method is executed in another thread (posting notifications "across threads"). This probably isn't a big deal if you are using mutexes (assuming you don't actually care which thread carries out the task associated with the notification posting), but as I said before, this is not what I'm after.
I don't know what you are really after.
Allow me to attempt to explain a second time, in a more concise fashion.
My app will have multiple, persistent TCP connections open, one connection per remote device. The user will be able to select a task to execute on a particular device that we have a connection open to, and get back from the application real-time updates as to the progress or results of the execution of that task. In certain cases, the length of the task is infinite; it will keep executing forever and sending back results to my application which will update its display of the results every second that ticks by until the user STOPS that particular task.
This can be done simply using async I/O in the main runloop, sure. But if I were going to thread this so that I could be processing the results I've received back from one *or more* remote devices while also doing something else, given that I will only have one (persistent) connection open to any given remote device that I'm interacting with (that is to say, I won't be opening up a separate TCP session for every single task I want to execute on a single device simultaneously), it makes sense _to me_ to implement this as I've described: with every connection to each remote device getting its own thread that lasts for the lifetime of the TCP session (which could be the entire time the application is running, times however many devices the user wishes to be connected to while in the app). I won't be spawning a new thread for every task the user wishes to ask a remote device to do.
This is why (I think) I need bi-directional messaging between the main thread and each of these threads dedicated to a given remote device that we have an active session with/connection to. The main thread needs to be able to tell remote device X (which already has a running thread dedicated to it) to do task A, and then get real-time feedback from that remote device so that the main thread can be displaying it to the user as it is coming back. Same with remote device Y running task B, simultaneously. At any time during the execution of these tasks, the user needs to be able to tell my app to stop one of these tasks, and the main thread needs to send that message to one of the remote devices via that device's dedicated thread.
This is why I am talking about this in terms of the "actor model," and not the "worker thread model," because the former model seems to fit what I want to do.
-- Nathan

Problem with threads hanging

We have a problem where our application stops responding after a few days of usage. Things will for fine for a day or two, and then pretty quickly threads will start getting hung up, usually in places where they are allocating memory
We are running WebLogic 8.1 SP2 on Sun JDK 1.4.2_04 on Solaris 8 using the alternate threading model and the -server hotspot vm. We are running pretty much the same code that we had no problems with under WebLogic 6.1 SP4 and Sun JDK 1.3.1.
A thread dump usually shows that some or all of our execute threads are in the state "waiting for monitor entry" even though they are not currently waiting on any java locks. Here is a sample thread from the thread dump (we have ~120 threads so I don't want to post the full dump).
=============================================================================================
"ExecuteThread: '8' for queue: 'itgCrmWarExecutionQueue'" daemon prio=5 tid=0x005941d0 nid=0x2c waiting for monitor entry [c807f000..c807fc28]
at java.lang.String.substring(String.java:1446)
at java.lang.String.substring(String.java:1411)
at weblogic.servlet.internal.ServletRequestImpl.getRelativeUri(ServletRequestImpl.java:1872)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3492)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2585)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
=============================================================================================
String.java line 1446 for this jdk allocates a new String object, and all the other threads in this state also are creating new objects or arrays, etc.
We've done a pstack on this process when it's in this state, and the threads that are in the "waiting for monitor entry" that look like they're allocating memory are all waiting on the same lwp_mutex_lock with some allocation method that's calling into the native TwoGenerationCollectorPolicy.mem_allocate_work (see pstack output below for the same thread as in the thread dump above)
=============================================================================================
----------------- lwp# 44 / thread# 44 --------------------
ff31f364 lwp_mutex_lock (e3d70)
fee92384 __1cNObjectMonitorGenter26MpnGThread__v_ (5000, 525c, 5000, 50dc, 4800, 4af0) + 2d8
fee324d4 __1cSObjectSynchronizerKfast_enter6FnGHandle_pnJBasicLock_pnGThread__v_ (c807f65c, c807f7d4, 5941d0, 0, 35d654, fee328ec) + 68
fee32954 __1cQinstanceRefKlassZacquire_pending_list_lock6FpnJBasicLock__v_ (c807f7d4, ff170000, d4680000, 4491d4, fee1bc2c,
0) + 78
fee3167c __1cPVM_GC_OperationNdoit_prologue6M_i_ (c807f7bc, 4400, ff170000, 2d2b8, 4a6268, c807fa18) + 38
fee2e0b0 __1cIVMThreadHexecute6FpnMVM_Operation__v_ (c807f7bc, 963a8, 0, 0, 1, 0) + 90
fed2c2a4 __1cbCTwoGenerationCollectorPolicyRmem_allocate_work6MIii_pnIHeapWord__ (962c0, ff1c29ec, ff1c297c, ff131a26, 4800, 4998) + 160
fed22940 __1cNinstanceKlassRallocate_instance6MpnGThread__pnPinstanceOopDesc__ (ee009020, 5941d0, 15ca581, 3647f0, 4a6268, c807f8c8) + 180
fed34928 __1cLOptoRuntimeFnew_C6FpnMklassOopDesc_pnKJavaThread__v_ (ee009018, 5941d0, 0, 0, 0, 0) + 28
fa435a58 ???????? (ee009018, e86de, 15ca4de, 50dc, 5941d0, c807f9c8)
fb36f9a4 ???????? (0, d412ccd8, ee046c28, ff170000, 0, 0)
fad8b278 ???????? (ee046c28, d6000c90, ee046530, 8, db8e8450, c807f9e8)
fad62abc ???????? (d412ccd8, ee046530, d6000c90, ee3bfa38, 8, c807fa18)
fa4b3c38 ???????? (c807fb9c, 0, f2134700, fa415e50, 8, c807faa8)
fa40010c ???????? (c807fc28, c807fe90, a, ee9e1e20, 4, c807fb40)
fed5d48c __1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_ (c807fe88, c807fcf0, c807fda8, 5941d0, 5941d0, c807fd00) + 27c
fee4b784 __1cJJavaCallsMcall_virtual6FpnJJavaValue_nLKlassHandle_nMsymbolHandle_4pnRJavaCallArguments_pnGThread__v_ (ff170000, 594778, c807fd9c, c807fd98, c807fda8, 5941d0) + 164
fee5e8dc __1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbolHandle_5pnGThread__v_ (c807fe88, c807fe84, c807fe7c, c807fe74, c807fe6c, 5941d0) + 6c
fee6fc74 __1cMthread_entry6FpnKJavaThread_pnGThread__v_ (5941d0, 5941d0, 838588, 594778, 306d10, fee69254) + 128
fee6927c __1cKJavaThreadDrun6M_v_ (5941d0, 2c, 40, 0, 40, 0) + 284
fee6575c _start   (5941d0, fa1a1600, 0, 0, 0, 0) + 134
ff3758c0 lwpstart (0, 0, 0, 0, 0, 0)
=============================================================================================
Also when it's having this problem, the "VM Thread" is always using a lot of processor time. We did a couple of pstacks today while it was having this problem, and this thread was stuck in the ONMethodSweeper.sweep for over 15 minutes when we finally killed the server.
From the thread dump:
"VM Thread" prio=5 tid=0x000e2d20 nid=0x2 runnable
From the first pstack:
=============================================================================================
----------------- lwp# 2 / thread# 2 --------------------
fed40c04 __1cXvirtual_call_RelocationIparse_ic6FrpnICodeBlob_rpC5rppnHoopDesc_pi_nNRelocIterator__ (42a2f4, fa5fa46d, ffffffff, fc4ffcb8, 42a2f4, 42a324) + 124
fed46318 __1cKCompiledIC2t5B6MpnKRelocation__v_ (42a2f0, fc4ffd24, fc4ffd4c, e802, 0, 6) + 38
fed90c38 __1cHnmethodVcleanup_inline_caches6M_v_ (fa5f7f88, fa608940, 1, 0, fa400000, 6) + 1ac
fede18b4 __1cONMethodSweeperFsweep6F_v_ (2cf38, 0, ffffffff, ff1cf1fc, ff1c66e8, fede1d44) + 1b0
fede1e6c __1cUSafepointSynchronizeFbegin6F_v_ (2cf38, ff1ba138, 5000, 50dc, 5000, 525c) + 248
feef1fd4 __1cIVMThreadEloop6M_v_ (4400, 4000, 4324, 4000, 42b0, 3800) + 3d4
feef1ae4 __1cIVMThreadDrun6M_v_ (e2d20, 2, 40, 0, 40, 0) + 8c
fee6575c _start   (e2d20, ff270200, 0, 0, 0, 0) + 134
ff3758c0 lwpstart (0, 0, 0, 0, 0, 0)
=============================================================================================
Second pstack
=============================================================================================
----------------- lwp# 2 / thread# 2 --------------------
fed41180 __1cXvirtual_call_RelocationIparse_ic6FrpnICodeBlob_rpC5rppnHoopDesc_pi_nNRelocIterator__ (0, ff1b9664, ffffffff, fc4ffcb8, a6f2cc, fc4ffbd0) + 6a0
fed46318 __1cKCompiledIC2t5B6MpnKRelocation__v_ (a6f2c8, fc4ffd24, fc4ffd4c, e802, 0, 6) + 38
fed90c38 __1cHnmethodVcleanup_inline_caches6M_v_ (faded4c8, fadf2c80, 1, 0, fa400000, 6) + 1ac
fede18b4 __1cONMethodSweeperFsweep6F_v_ (2cf38, 0, ffffffff, ff1cf1fc, ff1c66e8, fede1d44) + 1b0
fede1e6c __1cUSafepointSynchronizeFbegin6F_v_ (2cf38, ff1ba138, 5000, 50dc, 5000, 525c) + 248
feef1fd4 __1cIVMThreadEloop6M_v_ (4400, 4000, 4324, 4000, 42b0, 3800) + 3d4
feef1ae4 __1cIVMThreadDrun6M_v_ (e2d20, 2, 40, 0, 40, 0) + 8c
fee6575c _start   (e2d20, ff270200, 0, 0, 0, 0) + 134
ff3758c0 lwpstart (0, 0, 0, 0, 0, 0)
=============================================================================================
Has anyone ever seen anything like this? I'm trying to figure out if this is caused by something we're doing, or something relating to our environment and jvm options. Any ideas?

Thanks for the reply - I'm testing our app with the +UseConcMarkSweepGC now in our test environment to make sure it doesn't cause any problems there. Unfortunately the only place we've had this problem is on the production server, so it's extra difficult debugging this.
We're using the following memory options:
-ms512m -mx512m -XX:NewSize=128m -XX:PermSize=192m -XX:MaxNewSize=128m -XX:MaxPermSize=192m -XX:SurvivorRatio=8and the following debugging options, as we've also been seeing OutOfMemoryErrors ( see http://forum.java.sun.com/thread.jsp?forum=37&thread=522354&tstart=45&trange=15 )
-verbosegc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGCBTW, which c++filt version and options are you using? Our Solaris boxes only seem to have the GNU version installed. I was trying to run that on some of the other stack traces and wasn't getting anywhere, and didn't know if because it was GNU version wouldn't work on something compiled with the Sun compiler.
Thanks!
--Andy

Can't fill ByteArray in EJB-Method with generated Model-Class from WD-Model

Hello everybody,
i try to call an ejb-method with data from an FileUpload-UI-Element in WD. The EJB-Method is receiving the byte-data to create a document in KM via a Web-Service.
The ebj-methid has the following signature:
public FObject putFileDataSimple (byte [] btContent, String fullFileName, String username, String password)
After importing the Model and creating a context node i have the following structure:
Request_X_putFileDataSimple
+---btContent (Node)
      +-- item
+ fullFileName
+ username
+ password
btContent is of the generated Type Byte_Item, which is itself a generated Model-Class of modelClassType ARRAY
item is of Type byte
But i simply have problems to fill the context node (or the binded model-object). i tried different ways and looked at thread [https://www.sdn.sap.com/irj/scn/thread?messageID=1954223] but i cant get it work.
So my Method in WD looks like this to fill the structure and start the ejb-method:
public boolean putKMDataSimple( com.sap.tc.webdynpro.services.sal.datatransport.api.IWDResource fin ) {
try
wdContext.currentRequest_X_putFileDataSimpleElement().setFullFileName("abc");
wdContext.currentRequest_X_putFileDataSimpleElement().setUsername("def");
wdContext.currentRequest_X_putFileDataSimpleElement().setPassword("xxx");
byte[] buffer = new byte[1];
InputStream in = fin.read(false);
int i = 1;
int j = 0;
while (i!=-1)
     i = in.read(buffer);
     if (i!=-1)
       Byte_Item bi = new Byte_Item(mAlf);     // mAlf ist global defined Model-Class-Instance
       bi.setItem(buffer[0]);
        wdContext.currentRequest_X_putFileDataSimpleElement().modelObject().addBtContent(bi);
wdContext.currentRequest_X_putFileDataSimpleElement().modelObject().execute();
Doing this results in Error-Messages like:
Model-Object is not a complex type for every byte added this way.
And finally an IllegalArgumentException at java.lang.reflect.Array.set(Native Method)
The second way i tried is:
public boolean putKMDataSimple( com.sap.tc.webdynpro.services.sal.datatransport.api.IWDResource fin ) {
try
wdContext.currentRequest_X_putFileDataSimpleElement().setFullFileName("abc");
wdContext.currentRequest_X_putFileDataSimpleElement().setUsername("def");
wdContext.currentRequest_X_putFileDataSimpleElement().setPassword("xxx");
byte[] buffer = new byte[1];
ArrayList<Byte> btlist = new ArrayList<Byte>();
InputStream in = fin.read(false);
int i = 1;
int j = 0;
while (i!=-1)
     i = in.read(buffer);
     if (i!=-1)
          btList.add(buffer[0]);
wdContext.currentRequest_X_putFileDataSimpleElement().modelObject().setBtContent(btList);
wdContext.currentRequest_X_putFileDataSimpleElement().modelObject().execute();
Trying so results in:
java.lang.ClassCastException: class java.lang.Byte:null incompatible with interface com.sap.tc.cmi.model.ICMIModelClass:library:com.sap.tc.cmi(at-sign)[email protected]@alive
whenn calling the setBtContent Method
I don't what to do now to fill the context/model-object the right way.
Any helpfull hints are very welcome
Edited by: Matthias Hayk on Dec 1, 2008 5:51 PM
Edited by: Matthias Hayk on Dec 2, 2008 10:56 AM

Ok Vesselin and thanx for your idea,
so i adapted the source in the way you told like the following:
                 ArrayList<Byte_Item> btlist = new ArrayList<Byte_Item>();
                 byte[] buffer = new byte[1];
                 InputStream in = fin.read(false);
                 int i = 1;
                 int j = 0;
                 while (i!=-1)
                      i = in.read(buffer);
                      if (i!=-1)
                           // Byte gelesen
                           Byte_Item bi = new Byte_Item(mAlf);
                           bi.setItem(buffer[0]);
                           btlist.add(bi);
                           j++;
                 wdContext.currentRequest_X_putFileDataSimpleElement().modelObject().setBtContent(btlist);
                 wdContext.currentRequest_X_putFileDataSimpleElement().modelObject().execute();
This results also in the following Exception when exceuting the WS-proxy:
execute
[EXCEPTION]
java.lang.IllegalArgumentException
at java.lang.reflect.Array.set(Native Method)
at com.sap.tc.webdynpro.model.ejb.model.EJBGenericModelClassExecutable.getInputParameters(EJBGenericModelClassExecutable.java:215)
at com.sap.tc.webdynpro.model.ejb.model.EJBGenericModelClassExecutable.execute(EJBGenericModelClassExecutable.java:112)

Creator Freeze Often -- SWING Worker thread also

I'm developping an app with creator. And I have many freezes in several minutes long as some people mentioned before.
I'm running win XP on an opeteron 244(1.8G) x2 , with 2G memory. I've updated creator to the latest updates, but it doesn't seem to be better.
The things I found is that when I edit Session Bean , Creator takes especially long time to come up.
At that time, SWING worker thread of Creator IDE also stopping, No update of display , I only look window frame.
You know the SWING has a Single thread model ,so if some logic uses SWING worker's thread long time, all displying process will be stopped.
Below is the stacktrace just after a few seconds when Creator freeze by editing Session Bean.
I use the stacktrace tool at http://tmitevski.users.mcs2.netarray.com/trace.do
Full thread dump Java HotSpot(TM) Client VM (1.5.0_04-b05 mixed mode):
"StackTrace Remote Thread" prio=5 tid=0x48b10418 nid=0x368 waiting on condition [0x00000000..0x4e85fbac]
"Inactive RequestProcessor thread [Was:TimedWeakReference/org.netbeans.modules.projectapi.TimedWeakReference]" daemon prio=2 tid=0x48cc9e78 nid=0x634 in Object.wait() [0x4e89f000..0x4e89fbe8]
     at java.lang.Object.wait(Native Method)
     at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:692)
     - locked <0x1eeb8620> (a java.lang.Object)
"Inactive RequestProcessor thread [Was:Default RequestProcessor/org.netbeans.modules.editor.NbEditorUI$2]" daemon prio=2 tid=0x48d00d18 nid=0x814 in Object.wait() [0x4e79f000..0x4e79fce8]
     at java.lang.Object.wait(Native Method)
     at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:692)
     - locked <0x1eeb8690> (a java.lang.Object)
"Inactive RequestProcessor thread [Was:Java Children Provider/org.netbeans.modules.java.ui.nodes.elements.SourceChildren$4]" daemon prio=2 tid=0x48ce0d98 nid=0xd8c in Object.wait() [0x4e65f000..0x4e65fae8]
     at java.lang.Object.wait(Native Method)
     at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:692)
     - locked <0x1edbfe00> (a java.lang.Object)
"Inactive RequestProcessor thread [Was:Suggestions Broker/org.netbeans.modules.tasklist.suggestions.SuggestionsBroker$2]" daemon prio=2 tid=0x473e1c80 nid=0x9fc in Object.wait() [0x4b84f000..0x4b84fbe8]
     at java.lang.Object.wait(Native Method)
     at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:692)
     - locked <0x1ed09d38> (a java.lang.Object)
"Timer-48" prio=7 tid=0x492d4748 nid=0x930 in Object.wait() [0x4e43f000..0x4e43fa68]
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:474)
     at java.util.TimerThread.mainLoop(Timer.java:483)
     - locked <0x1eb90290> (a java.util.TaskQueue)
     at java.util.TimerThread.run(Timer.java:462)
"Timer-46" prio=7 tid=0x4831ede8 nid=0xff0 in Object.wait() [0x4e71f000..0x4e71fae8]
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:474)
     at java.util.TimerThread.mainLoop(Timer.java:483)
     - locked <0x1ea9f428> (a java.util.TaskQueue)
     at java.util.TimerThread.run(Timer.java:462)
"Timer-44" prio=7 tid=0x48b26ab0 nid=0xc50 in Object.wait() [0x4e81f000..0x4e81fb68]
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:474)
     at java.util.TimerThread.mainLoop(Timer.java:483)
     - locked <0x1dc0d688> (a java.util.TaskQueue)
     at java.util.TimerThread.run(Timer.java:462)
"Timer-42" prio=7 tid=0x50f3bb68 nid=0x8f0 in Object.wait() [0x4e7df000..0x4e7dfa68]
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:474)
     at java.util.TimerThread.mainLoop(Timer.java:483)
     - locked <0x1db078b8> (a java.util.TaskQueue)
     at java.util.TimerThread.run(Timer.java:462)
"Timer-40" prio=7 tid=0x48bbde20 nid=0xf0c in Object.wait() [0x4e75f000..0x4e75f9e8]
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:474)
     at java.util.TimerThread.mainLoop(Timer.java:483)
     - locked <0x1d85d2b8> (a java.util.TaskQueue)
     at java.util.TimerThread.run(Timer.java:462)
"Timer-38" prio=7 tid=0x50e67840 nid=0x8a4 in Object.wait() [0x4e6df000..0x4e6dfae8]
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:474)
     at java.util.TimerThread.mainLoop(Timer.java:483)
     - locked <0x1d7bc160> (a java.util.TaskQueue)
     at java.util.TimerThread.run(Timer.java:462)
"Timer-36" prio=7 tid=0x48ba3f50 nid=0xf58 in Object.wait() [0x4e5df000..0x4e5dfd68]
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:474)
     at java.util.TimerThread.mainLoop(Timer.java:483)
     - locked <0x1d7bc1d8> (a java.util.TaskQueue)
     at java.util.TimerThread.run(Timer.java:462)
"Timer-34" prio=7 tid=0x48abb270 nid=0xee8 in Object.wait() [0x4e53f000..0x4e53fb68]
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:474)
     at java.util.TimerThread.mainLoop(Timer.java:483)
     - locked <0x1d339d68> (a java.util.TaskQueue)
     at java.util.TimerThread.run(Timer.java:462)
"Timer-32" prio=7 tid=0x47a6e050 nid=0xe98 in Object.wait() [0x4e69f000..0x4e69fa68]
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:474)
     at java.util.TimerThread.mainLoop(Timer.java:483)
     - locked <0x1b93e2e8> (a java.util.TaskQueue)
     at java.util.TimerThread.run(Timer.java:462)
"Timer-30" prio=7 tid=0x4925bd38 nid=0x9a8 in Object.wait() [0x4e4bf000..0x4e4bfa68]
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:474)
     at java.util.TimerThread.mainLoop(Timer.java:483)
     - locked <0x1b3022f0> (a java.util.TaskQueue)
     at java.util.TimerThread.run(Timer.java:462)
"Timer-28" prio=7 tid=0x4930aae8 nid=0x620 in Object.wait() [0x4b70f000..0x4b70fae8]
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:474)
     at java.util.TimerThread.mainLoop(Timer.java:483)
     - locked <0x1af19770> (a java.util.TaskQueue)
     at java.util.TimerThread.run(Timer.java:462)
"Timer-26" prio=7 tid=0x485620c8 nid=0x120 in Object.wait() [0x4e59f000..0x4e59fb68]
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:474)
     at java.util.TimerThread.mainLoop(Timer.java:483)
     - locked <0x1978f0f8> (a java.util.TaskQueue)
     at java.util.TimerThread.run(Timer.java:462)
"Timer-24" prio=7 tid=0x46d7e9e8 nid=0xaf8 in Object.wait() [0x4e61f000..0x4e61fbe8]
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:474)
     at java.util.TimerThread.mainLoop(Timer.java:483)
     - locked <0x196f19e8> (a java.util.TaskQueue)
     at java.util.TimerThread.run(Timer.java:462)
"VCS Command Tasks Starter Loop" daemon prio=2 tid=0x48aeed00 nid=0x96c in Object.wait() [0x4e4ff000..0x4e4ffbe8]
     at java.lang.Object.wait(Native Method)
     - waiting on <0x18841770> (a org.netbeans.modules.vcscore.commands.CommandProcessor)
     at java.lang.Object.wait(Object.java:474)
     at org.netbeans.modules.vcscore.commands.CommandProcessor.executorStarterLoop(CommandProcessor.java:757)
     - locked <0x18841770> (a org.netbeans.modules.vcscore.commands.CommandProcessor)
     at org.netbeans.modules.vcscore.commands.CommandProcessor.access$700(CommandProcessor.java:65)
     at org.netbeans.modules.vcscore.commands.CommandProcessor$5.run(CommandProcessor.java:776)
     at java.lang.Thread.run(Thread.java:595)
"Timer-16" prio=7 tid=0x46fa81a8 nid=0x69c in Object.wait() [0x4e3ff000..0x4e3ffd68]
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:474)
     at java.util.TimerThread.mainLoop(Timer.java:483)
     - locked <0x151bf408> (a java.util.TaskQueue)
     at java.util.TimerThread.run(Timer.java:462)
"Timer-12" prio=7 tid=0x479eacf0 nid=0x2ec in Object.wait() [0x4b4df000..0x4b4dfce8]
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:474)
     at java.util.TimerThread.mainLoop(Timer.java:483)
     - locked <0x1499b4e8> (a java.util.TaskQueue)
     at java.util.TimerThread.run(Timer.java:462)
"URLdisplayer" prio=7 tid=0x4865de20 nid=0xe2c in Object.wait() [0x4727f000..0x4727fd68]
     at java.lang.Object.wait(Native Method)
     - waiting on <0x12a02bb0> (a org.netbeans.modules.extbrowser.NbDdeBrowserImpl$URLDisplayer)
     at java.lang.Object.wait(Object.java:474)
     at org.netbeans.modules.extbrowser.NbDdeBrowserImpl$URLDisplayer.getNextTask(NbDdeBrowserImpl.java:223)
     - locked <0x12a02bb0> (a org.netbeans.modules.extbrowser.NbDdeBrowserImpl$URLDisplayer)
     at org.netbeans.modules.extbrowser.NbDdeBrowserImpl$URLDisplayer.run(NbDdeBrowserImpl.java:235)
     at java.lang.Thread.run(Thread.java:595)
"Text-Layout" prio=2 tid=0x475967e8 nid=0xa68 in Object.wait() [0x4b68f000..0x4b68fae8]
     at java.lang.Object.wait(Native Method)
     - waiting on <0x129e8cd0> (a org.netbeans.editor.view.spi.ViewLayoutQueue)
     at java.lang.Object.wait(Object.java:474)
     at org.netbeans.editor.view.spi.ViewLayoutQueue.waitForTask(ViewLayoutQueue.java:128)
     - locked <0x129e8cd0> (a org.netbeans.editor.view.spi.ViewLayoutQueue)
     at org.netbeans.editor.view.spi.ViewLayoutQueue$LayoutThread.run(ViewLayoutQueue.java:182)
"MDR event dispatcher" daemon prio=2 tid=0x47b8b450 nid=0x9c8 in Object.wait() [0x4b88f000..0x4b88fa68]
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:474)
     at org.netbeans.mdr.util.EventNotifier$EventsDelivery.run(EventNotifier.java:257)
     - locked <0x087d1b10> (a java.util.LinkedList)
     at java.lang.Thread.run(Thread.java:595)
"DestroyJavaVM" prio=5 tid=0x00038890 nid=0x4e4 waiting on condition [0x00000000..0x0007fae8]
"TimerQueue" daemon prio=5 tid=0x46da6908 nid=0x768 in Object.wait() [0x4716f000..0x4716fb68]
     at java.lang.Object.wait(Native Method)
     at javax.swing.TimerQueue.run(TimerQueue.java:233)
     - locked <0x07b22b68> (a javax.swing.TimerQueue)
     at java.lang.Thread.run(Thread.java:595)
"AWT-EventQueue-1" prio=7 tid=0x46ea8478 nid=0x990 runnable [0x4820e000..0x4820fbe8]
     at java.net.Inet4AddressImpl.getHostByAddr(Native Method)
     at java.net.InetAddress$1.getHostByAddr(InetAddress.java:842)
     at java.net.InetAddress.getHostFromNameService(InetAddress.java:532)
     at java.net.InetAddress.getHostName(InetAddress.java:475)
     at java.net.InetAddress.getHostName(InetAddress.java:447)
     at java.net.InetSocketAddress.getHostName(InetSocketAddress.java:210)
     at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:341)
     at java.net.Socket.connect(Socket.java:507)
     at java.net.Socket.connect(Socket.java:457)
     at java.net.Socket.<init>(Socket.java:365)
     at java.net.Socket.<init>(Socket.java:207)
     at com.mysql.jdbc.StandardSocketFactory.connect(StandardSocketFactory.java:142)
     at com.mysql.jdbc.MysqlIO.<init>(MysqlIO.java:280)
     at com.mysql.jdbc.Connection.createNewIO(Connection.java:1774)
     at com.mysql.jdbc.Connection.<init>(Connection.java:437)
     at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:268)
     at com.sun.rave.sql.DesignTimeDataSource.getConnection(DesignTimeDataSource.java:238)
     at com.sun.rave.sql.DesignTimeDataSource.getConnection(DesignTimeDataSource.java:214)
     at com.sun.sql.rowset.JdbcRowSetXImpl.connect(JdbcRowSetXImpl.java:410)
     at com.sun.sql.rowset.JdbcRowSetXImpl.prepare(JdbcRowSetXImpl.java:532)
     at com.sun.sql.rowset.JdbcRowSetXImpl.execute(JdbcRowSetXImpl.java:349)
     at caico.jsf.svc.itemSvc.<init>(itemSvc.java:81)
     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
     at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
     at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
     at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
     at java.lang.Class.newInstance0(Class.java:350)
     at java.lang.Class.newInstance(Class.java:303)
     at com.sun.rave.insync.beans.BeansUnit.instantiateBean(BeansUnit.java:884)
     at com.sun.rave.insync.live.LiveUnit.ressurectDesignBean(LiveUnit.java:339)
     at com.sun.rave.insync.live.LiveUnit.resurrect(LiveUnit.java:406)
     at com.sun.rave.insync.live.LiveUnit.sync(LiveUnit.java:294)
     at com.sun.rave.insync.live.LiveUnitWrapper.sync(LiveUnitWrapper.java:115)
     at com.sun.rave.insync.models.FacesModel.syncImpl(FacesModel.java:899)
     at com.sun.rave.insync.Model.sync(Model.java:207)
     at com.sun.rave.insync.Model.sync(Model.java:173)
     at com.sun.rave.insync.ModelSet$WindowManagerPropertyRegistry.processNodes(ModelSet.java:107)
     at com.sun.rave.insync.ModelSet$WindowManagerPropertyRegistry.propertyChange(ModelSet.java:125)
     at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:333)
     at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:270)
     at org.netbeans.core.windows.RegistryImpl.doFirePropertyChange(RegistryImpl.java:249)
     at org.netbeans.core.windows.RegistryImpl.tryFireChanges(RegistryImpl.java:222)
     at org.netbeans.core.windows.RegistryImpl.selectedNodesChanged(RegistryImpl.java:186)
     at org.netbeans.core.windows.RegistryImpl.topComponentActivated(RegistryImpl.java:138)
     at org.netbeans.core.windows.WindowManagerImpl.notifyRegistryTopComponentActivated(WindowManagerImpl.java:893)
     at org.netbeans.core.windows.Central.setActiveMode(Central.java:182)
     at org.netbeans.core.windows.Central.userActivatedMode(Central.java:1451)
     at org.netbeans.core.windows.view.DefaultView.userActivatedModeView(DefaultView.java:591)
     at org.netbeans.core.windows.view.ui.TabbedHandler$ActivationManager.handleActivation(TabbedHandler.java:477)
     at org.netbeans.core.windows.view.ui.TabbedHandler$ActivationManager.eventDispatched(TabbedHandler.java:425)
     at java.awt.Toolkit$SelectiveAWTEventListener.eventDispatched(Toolkit.java:2206)
     at java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java:2100)
     at java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java:2099)
     at java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java:2099)
     at java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java:2099)
     at java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java:2099)
     at java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java:2099)
     at java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java:2099)
     at java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java:2099)
     at java.awt.Toolkit.notifyAWTEventListeners(Toolkit.java:2058)
     at java.awt.Component.dispatchEventImpl(Component.java:3867)
     at java.awt.Container.dispatchEventImpl(Container.java:2024)
     at java.awt.Component.dispatchEvent(Component.java:3803)
     at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
     at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3889)
     at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)
     at java.awt.Container.dispatchEventImpl(Container.java:2010)
     at java.awt.Window.dispatchEventImpl(Window.java:1774)
     at java.awt.Component.dispatchEvent(Component.java:3803)
     at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
     at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
     at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
     at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
     at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
     at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
"Creator Error Handler Listener" prio=5 tid=0x4665f3d8 nid=0xf70 runnable [0x481cf000..0x481cfce8]
     at java.net.PlainSocketImpl.socketAccept(Native Method)
     at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
     - locked <0x0793baf0> (a java.net.SocksSocketImpl)
     at java.net.ServerSocket.implAccept(ServerSocket.java:450)
     at java.net.ServerSocket.accept(ServerSocket.java:421)
     at com.sun.rave.errorhandler.DebugServerThread.run(DebugServerThread.java:81)
"Java2D Disposer" daemon prio=10 tid=0x467d6760 nid=0xa08 in Object.wait() [0x46c8f000..0x46c8fce8]
     at java.lang.Object.wait(Native Method)
     at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
     - locked <0x07451380> (a java.lang.ref.ReferenceQueue$Lock)
     at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
     at sun.java2d.Disposer.run(Disposer.java:107)
     at java.lang.Thread.run(Thread.java:595)
"Active Reference Queue Daemon" daemon prio=2 tid=0x467bb638 nid=0xb70 in Object.wait() [0x46c4f000..0x46c4fd68]
     at java.lang.Object.wait(Native Method)
     at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
     - locked <0x07451408> (a java.lang.ref.ReferenceQueue$Lock)
     at org.openide.util.Utilities$ActiveQueue.run(Utilities.java:2465)
     at java.lang.Thread.run(Thread.java:595)
"Timer-0" daemon prio=5 tid=0x4678f2f0 nid=0xaf0 in Object.wait() [0x46c0f000..0x46c0f9e8]
     at java.lang.Object.wait(Native Method)
     at java.util.TimerThread.mainLoop(Timer.java:509)
     - locked <0x07451498> (a java.util.TaskQueue)
     at java.util.TimerThread.run(Timer.java:462)
"AWT-Windows" daemon prio=7 tid=0x467a54a0 nid=0x790 runnable [0x46a6f000..0x46a6fa68]
     at sun.awt.windows.WToolkit.eventLoop(Native Method)
     at sun.awt.windows.WToolkit.run(WToolkit.java:269)
     at java.lang.Thread.run(Thread.java:595)
"AWT-Shutdown" prio=5 tid=0x467a5008 nid=0xafc in Object.wait() [0x46a2f000..0x46a2fae8]
     at java.lang.Object.wait(Native Method)
     - waiting on <0x07451568> (a java.lang.Object)
     at java.lang.Object.wait(Object.java:474)
     at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:259)
     - locked <0x07451568> (a java.lang.Object)
     at java.lang.Thread.run(Thread.java:595)
"CLI Requests Server" daemon prio=5 tid=0x4676b380 nid=0xa64 runnable [0x4693f000..0x4693fbe8]
     at java.net.PlainSocketImpl.socketAccept(Native Method)
     at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
     - locked <0x07451720> (a java.net.SocksSocketImpl)
     at java.net.ServerSocket.implAccept(ServerSocket.java:450)
     at java.net.ServerSocket.accept(ServerSocket.java:421)
     at org.netbeans.CLIHandler$Server.run(CLIHandler.java:758)
"Low Memory Detector" daemon prio=5 tid=0x00ab83b8 nid=0xee0 runnable [0x00000000..0x00000000]
"CompilerThread0" daemon prio=10 tid=0x00ab7020 nid=0x9c4 waiting on condition [0x00000000..0x465cfa4c]
"Signal Dispatcher" daemon prio=10 tid=0x00ab6470 nid=0x31c runnable [0x00000000..0x00000000]
"Finalizer" daemon prio=9 tid=0x00aa95e0 nid=0x85c in Object.wait() [0x4654f000..0x4654fa68]
     at java.lang.Object.wait(Native Method)
     at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
     - locked <0x074519c0> (a java.lang.ref.ReferenceQueue$Lock)
     at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
     at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
"Reference Handler" daemon prio=10 tid=0x00aa8150 nid=0xf1c in Object.wait() [0x4650f000..0x4650fae8]
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:474)
     at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
     - locked <0x07451590> (a java.lang.ref.Reference$Lock)
"VM Thread" prio=10 tid=0x00aa5780 nid=0x808 runnable
"VM Periodic Task Thread" prio=10 tid=0x00ab9858 nid=0x1b0 waiting on condition

Use a SwingUtilities.invokeLater(...) to invoke the main GUI. This will allow the button to repaint itself before the main GUI is invoked.

Using boost::thread with Sun Studio C++ gives error

Hi,
I'm trying to compile a code which uses the boost thread library, but I get the following error:
CC -library=stlport4 -features=tmplife -features=tmplrefstatic -mt -c -o t t.cpp
"/opt/boost/include/boost/thread/pthread/mutex.hpp", line 142: Error: The function "pthread_mutex_timedlock" must have a prototype.
"/opt/boost/include/boost/thread/pthread/mutex.hpp", line 142: Error: The function "pthread_mutex_timedlock" must have a prototype.
"/opt/boost/include/boost/thread/detail/thread.hpp", line 344: Error: boost::thread::thread(boost::thread&) is not accessible from boost::move(boost::detail::thread_move_t<boost::thread>).
"/opt/boost/include/boost/thread/pthread/recursive_mutex.hpp", line 179: Error: The function "pthread_mutex_timedlock" must have a prototype.
"/opt/boost/include/boost/thread/pthread/recursive_mutex.hpp", line 179: Error: The function "pthread_mutex_timedlock" must have a prototype.
5 Error(s) detected.
make: *** [t] Error 5the sample source code in question here just a single include:
#include <boost/thread.hpp>This is with boost 1.40.0. I wonder what I'm doing wrong..
Akos

OK, I tried latest version of CC from Sun Studio 12 update 1 and can say that
- the error about constructor not being accessible is Sun C++ compiler "feature" (only called feature because it existed for so long) that allows binding of rvalues to non-const references; this "feature" will probably be turned off in the next release. It can't be changed in a patch because client's code might rely on it.
- the other errors are also not Boost-specific: the result of incompatibility of Linux headers and Sun C++ compiler; more thorough investigation is due, but in the past we had several problems like this. This particular can be solved by adding
-D_GNU_SOURCE to compile line.

Native pthread mutex on 1:1 threading model

Similar Messages

Maybe you are looking for