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

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

Similar Messages

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

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

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

RDBMS non-thread-safe issue

<snip>
This (as you probably know) is due to the fact that the code provided by
most of the DB vendors is not thread safe.
<snip>
Sean's comment, above, speaks to an issue that is causing some concern
within my (large - 180 projects in development) organisation.
May I please ask the forum if there are others out there who have an
understanding of / concern with this "problem"?
My perception (quite possibly flawed) of the "problem" is that the RDBMS
cannot multi-thread data access objects. So we find ourselves in a situation
where we can achieve scaleability in just about all other
performance-sensitive areas of a system's technical architecture (we're
using DCE -- but have found that Encina is not advisable except where there
is a true requirement for heterogeneous distributed 2 phase commit, which we
don't often see.....) but when we go to hit on the RDBMS, we go back to good
ole single-threading.
In certain circumstances, this shortfall of RDBMS technology -- I won't
mention any names, of course, but the initials are "Oracle" -- seems to be
hindering our achievement of a desired technical architecture.
Is this a "Pro*C / PL/SQL stored procedures" problem or is it something that
is in the RDBMSs' DNA?
How can we get around it?
Any comments?
Regards
Jon

Jon
I agree. But it is the best solution within the constraints of existing
technology. At least we don't use a process per client. 10 replicated
copies of a service could service the needs of 100 clients.
Eric
>
At 13:15 6/09/96 EST, you wrote:
Eric
Thanks for your response. Yep. I realise that the issue I've presented is
clearly not something that Forte causes or is responsible for in any way.
Forte can, as you've pointed out, actually help in this area. But I don't
think that getting Forte to spawn another instance of a data access server
is really the best solution. Ie, that's not what we tend to have in mind
when we think about "scaleability". The best solution is -- perhaps -- to
get the RDBMS people to thread-safe all code and libraries. I have pointedly
asked Oracle for a position on this -- and got the usual blank stare.
I also considered whether people might get upset at me for posting what is
clearly a non-Forte-specifc question in a Forte forum. But then I went ahead
and did it anyway. Justification being (assumption follows) that the kind of
people who hang out on the Forte forum may tend to be more
architecture-oriented than your run of the mill VB / SQL*Net / PL/SQL stored
procedures kinda guy/gal, and may be using or considering Forte (plug for
Forte follows) precisely because it clearly enables a superior architecture.
Should proably post to the comp.database.oracle forum, but I just don't know
them as well.
Regards
Jon
From: Eric Gold
To: McLeod, Jon
Cc: [email protected]
Subject: Re: RDBMS non-thread-safe issue
Date: Friday, 6 September 1996 11:21AM
Jon
In response to this message.....read below...
Sean's comment, above, speaks to an issue that is causing some concern
within my (large - 180 projects in development) organisation.
May I please ask the forum if there are others out there who have an
understanding of / concern with this "problem"?
My perception (quite possibly flawed) of the "problem" is that the RDBMS
cannot multi-thread data access objects. So we find ourselves in a situation
where we can achieve scaleability in just about all other
performance-sensitive areas of a system's technical architecture (we're
using DCE -- but have found that Encina is not advisable except where there
is a true requirement for heterogeneous distributed 2 phase commit, which we
don't often see.....) but when we go to hit on the RDBMS, we go back to good
ole single-threading.
In certain circumstances, this shortfall of RDBMS technology -- I won't
mention any names, of course, but the initials are "Oracle" -- seems to be
hindering our achievement of a desired technical architecture.
Is this a "Pro*C / PL/SQL stored procedures" problem or is it something that
is in the RDBMSs' DNA?
How can we get around it?
Any comments?Jon,
Go ahead ask the Forum any questions you want. This "problem"
is not a problem in Forte. What we allow you to do is "replicate" your
data access services so that each one runs inside its own
process. Each one of these processes (aka partitions) has its
own connection to the database. The routing to the replicated
partitions is transparent to the clients. Clients send a
message like "DatabaseService.GetCustomer()" and then the Forte
router sees which replicated copy of the service is not currently
processing a request and routes it to that free replicate. You
can dynamically increase or decrease the number of replicated
copies of the service easily.
We call this feature "load balancing" in Forte. It is achieved
by checking a box in the data access service object definition.
You can dynamically increase/decrease the number of replicates
and also dynamically move replicates to other nodes in the environment.
This approach assumes that you are using application driven
security and not database security. Each replicated copy
of the service is using the same generic username/password
to connect to the database.
I am forwarding this answer to forte-users because others
might not completely understand this feature.
Eric
Eric Gold
Technical Director
Forte Australia
Voice: 61-2-9926-1403
Fax: 61-2-9926-1401
Eric Gold
Technical Director
Forte Australia
Voice: 61-2-9926-1403
Fax: 61-2-9926-1401

SwingWorker process(List V chunks) but List isn't thread safe is it.

Folks,
Am I missing something or does
protected void process(List<V> chunks)in the new 1.6 javax.swing.SwingWorker represent a potential threading issue?
List isn't thread safe... so why not use a Vector, which is? Except that Vector is currently considered persona-non-grata by bigger brains than me.
Hmmm... Of course, I don't know which implementation of List is being used under the hood, so I suppose I just have to trust the Java Gods who built the new SwingWorker to have used a thread safe implementation... which is pretty good bet, I suppose...
Can anyone state categorically that it isn't a problem?
Thanx. Keith.
Message was edited by: corlettk PS: I'm knee deep in thread gruel and going down fast.

publish definitely does not block until process is finished.
In fact calling publish does not necessarily mean that process will be called right away.
From the API:
Because the process method is invoked asynchronously on the Event Dispatch Thread multiple invocations to the publish method might occur before the process method is executed. For performance purposes all these invocations are coalesced into one invocation with concatenated arguments.
For example:
publish("1");
publish("2", "3");
publish("4", "5", "6");
might result in:
process("1", "2", "3", "4", "5", "6")
Edit:
The only source I could find for AccumulativeRunnable (the class used to accumulate the arguments passed to publish) was here:
http://fisheye5.cenqua.com/browse/swingworker/src/java/org/jdesktop/swingworker/AccumulativeRunnable.java?r=1.2
which isn't necessarily the implementation in the JDK but it's probably close.
That shows that before process is called the accumulating list reference is nulled, meaning that there is no way that publish can append to the list during a call to process.
In fact calling publish as the same time as process is executing on the EDT appends the published arguments to a fresh list, leading to another call to process at some later time (in SwingWorker the delay between a call to publish and a call to process is at most 1000/30 milliseconds).
Message was edited by:
dwg

Locking a non-thread-safe DLL, innovative solutions?

Hi,
I need to be able to lock access to a non-thread-safe third party DLL, so that multiple threads cannot access DLL simultaneously. I know that I can use semaphore or a single element queue. Are there any other innovative solutions that would limit the access to the DLL to a single call simultaneously.
If I use either semaphores or single element queue and use the semaphore (queue) with the same name in multiple programs (independent VIs), will the access to the DLL be handled without problems i.e. no collisions can happen? What if I build multiple applications (.exe) or application libraries (.dll), does a single semaphore (queue) still work between different applications or do they need to be initiated from the same application?
Tomi
Message Edited by Tomi M on 03-06-2006 08:01 PM
Tomi Maila

Tomi M wrote:
One more thing, with
innovative solutions I meant something like the following. Is there a
way to use some properties of Labview execution system to automatically
restrict the access to the DLL i.e. allow only single thread with
certain properties to call the DLL while all other threads with the
same properties are waiting in the execution queue. So if I set the
execution priority to something specific and execution system to
another something specific, will Labview thisway restrict access to DLL
to be sequential?
The proper way to
call non multithread safe DLLs in LabVIEW is to configure the Call
Library Node in the configuration dialog to be NOT reentrant. This
tells LabVIEW that the DLL may behave badly or at least you do not want
LabVIEW to call the DLL just from any thread. LabVIEW then will call
this DLL function from the UI execution system which is guaranteed to
only have one single thread at all times and therefore protect your DLL
from being called frm different threads at the same time.
Rlf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Problems with accept () system call in Solaris 10

We are doing some prototyping in Solaris 10/Zones using TCP sockets and have encountered the problem the "accept" system call in Solaris 10 always seem to return immediately without waiting for clients to connect to it. The same program works fine under Solaris 9 without any problems.
So in the following call:
ssock = accept( sockfd, (struct sockaddr*)bind_address, &alen );
if( ssock < 0 )
printf( "Accept failed: ...\n" );
the program always prints "accept failed: " continuously. Is this a known issue?

The problem only occurs when we use INADDR_ANY to bind a socket. The program works as expected when we use real as well as virtual IP address configured for an interface on any Solaris Zone. When we use INADDR_ANY, error number is 14 (EFAULT, Bad Address).
Just wondering if we need to make any configuration changes in order to allow INADDR_ANY to work.

How to add new system call in solaris ?

Hi,
I want to add new system call in solaris. please inform me steps for adding new system call in solaris.
Thanks in advance,
Mahantesh.

Here's a Solaris 7 example I know there are others ...
http://access1.sun.com/cgi-bin/rinfo2html?267899.faq
I haven't seen a good example of how to support both the 32 and 63-bit environment.

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 this method thread safe?

Hi Guys
I have the following code:
public class MyClass extends HttpServlet {
     HttpSession session;
     public doGet(HttpServletRequest request, HttpServletResponse response)
                                  throws IOException, ServletException
          session = request.getSession(false);
          List<AClass> htransactions = (List<AClass>)session.getAttribute("AClass");
               //do stuff here
}What I want to know is that if the HttpSession session is declared as a instance variable, does this make it non thread safe? Or is using such a way of for a session fine?
.

Steve declared a thumb-rule.
Bear Bibeault
sheriff & author
Member # 24697
posted Yesterday 9:17 PM
Yes, variables created inside methods are safe because each thread will get their own copies. Instance variables are unsafe because they are shared across all threads.
Keep this in memory, hope this was a perfect clarification...you can declare now on the answer.

Issuing Solaris system calls through Java

How can I issue a system call to Solaris using Java? (i.e. Start a script, open a file, and similar)

Hi Srini,
This is just a suggestion, but try entering the following commands (in your SQL*Plus session) before executing your stored procedure:
set serveroutput on size 1000000
exec dbms_java.set_output(1000000)Hope this helps.
Good Luck,
Avi.

Is system call multithread safe?

Dear all
Is system call are multithread safe?
i want to use system call eg (sysinfo)
is it multithread safe?
if you check man sysinfo
you couldnot find if it is multithread safe or not.
no any statement about it
could any of you give me some hints?

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

Is C++ list is thread safe??

we have a list<type name> which is accessed by two threads(update in one thread and deleted in another thread.)
mutex_lock and unlock are used. is insert by one thread is not reflected in another thread.
any reason?

When building a multi-threaded program, all CC command lines must include the -mt option. In that case, the default libCstd and optional STLport C++ runtime libraries are thread-safe.
Thread-safe means that the internal library code executed by different threads will not conflict. You still must provide your own guards for shared objects.
For example, suppose you have two lists, L1 and L2. If L1 is accessed only by thread 1 and L2 is accessed only by thread 2, you do not need special locking. If L1 is accessed by more than one thread, you must synchronize access to L1 yourself. You do not need to worry about the individual list functions or the implementation details of the list in either case..

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

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

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

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

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

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

Is ArrayList(Collection c) constructor Thread-Safe?

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

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

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

Similar Messages

Maybe you are looking for