It is currently Mon, 18 Nov 2019 23:17:20 GMT



 
Author Message
 Solaris 8 threads: If a routine is Async-Signal-Safe is it also thread Safe?
If a routine is Async-Signal-Safe is it also Safe? Is
Async-Signal-Safe a superset of Safe? I cannot tell this from the man
page for attributes(5).


 Tue, 19 Jul 2005 22:37:17 GMT   
 Solaris 8 threads: If a routine is Async-Signal-Safe is it also thread Safe?

The aforementioned man page mentions close(2) as an counterexample.

Bye, Dragan

--
Dragan Cvetkovic,

To be or not to be is true. G. Boole      No it isn't.  L. E. J. Brouwer



 Tue, 19 Jul 2005 22:47:11 GMT   
 Solaris 8 threads: If a routine is Async-Signal-Safe is it also thread Safe?

In practice, this is often the case, but in general there is no such
relationship.

For example, a routine might be made async-signal safe simply by masking all
signals during operation. (It's "safe" from a signal handler because the
handler cannot have interrupted the activity of another invocation of that
routine.) This doesn't mean it's thread-safe.

Of course, that's the comp.programming.threads answer, dealing with the
nature of the definitions. You might get a different answer based on the
formal usage of the terms in Solaris documentation. (Though I don't think
so.)

--
/--------------------[ David.Buten...@hp.com ]--------------------\
| Hewlett-Packard Company       Tru64 UNIX & VMS Thread Architect |
|     My book: http://www.awl.com/cseng/titles/0-201-63392-2/     |
\----[ http://homepage.mac.com/dbutenhof/Threads/Threads.html ]---/



 Wed, 20 Jul 2005 02:31:40 GMT   
 Solaris 8 threads: If a routine is Async-Signal-Safe is it also thread Safe?

You can't get any safer than "Async-Signal-Safe".

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.



 Wed, 20 Jul 2005 04:13:00 GMT   
 Solaris 8 threads: If a routine is Async-Signal-Safe is it also thread Safe?

No, it does not.  It says that close(2) is "Safe" but that you can
still use it unsafely.

Safe means that no "bad" things happen (like memory corruption or
program crashes; if one thread uses lseek() and the other write(),
strange things will happen yet both lseek() and write() are safe.)

Casper

--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.



 Wed, 20 Jul 2005 04:16:24 GMT   
 Solaris 8 threads: If a routine is Async-Signal-Safe is it also thread Safe?
Casper H.S. Dik <Casper....@Sun.COM> writes:

Hm, I'll say you are right but only because lseek(2)/write(2)/close(2) are
used for their side effects, not for the actual values they produce ...

Btw, if I do close(fd) in one thread and do write(fd, ...) in the other one
some time later, I should  get EBADF in the other one, shouldn't I?

Bye, Dragan

--
Dragan Cvetkovic,

To be or not to be is true. G. Boole      No it isn't.  L. E. J. Brouwer



 Wed, 20 Jul 2005 04:29:45 GMT   
 Solaris 8 threads: If a routine is Async-Signal-Safe is it also thread Safe?

Unless, some other open() has returned a fd with the same value.  Sort of like
holding a reference to memory that gets freed and reallocated somewhere else.
You won't get a segfault.  Except fd's are worse since they're generally reused
more often so you don't get EBADFs to warn you as frequently.

Joe Seigh



 Wed, 20 Jul 2005 04:42:10 GMT   
 Solaris 8 threads: If a routine is Async-Signal-Safe is it also thread Safe?

Yes.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.



 Wed, 20 Jul 2005 16:53:26 GMT   
 Solaris 8 threads: If a routine is Async-Signal-Safe is it also thread Safe?

Well, are you sure about that? Because it is a little different from
what I know. The async-signal-safe is also named reentrant, meaning it
uses no shared data, only stack variables are used.  So it is safe to
be called anywhere, ig. inside signal handlers.  To reach MT-safe, you
can merely use some sync objects, mutexes, whatever, but that does not
necessarily lead to signal safe.  The routine printf() is not signal
safe, but MT-safe, and write() is signal-safe.  Solaris manual
explicitely specifies routiine signal safety.

By masking signals, you can achieve signal safety, of course.  But is
it the way defined in POSIX?  I don't have the standard at hand.  But
I am a little suspicious.

Regards,

LG



 Sat, 23 Jul 2005 07:26:26 GMT   
 Solaris 8 threads: If a routine is Async-Signal-Safe is it also thread Safe?

Also, I am not sure if you can actually block signals in a thread; yes,
you can block signals in the *current* thread, but you cannot block them
in other threads.  So you the Async-signal-safe function can be called from
another thread even when signals are blocked.

So perhaps if you block signals and then lock a mutex, the async signal
safe function could conceivably modify global data; but I don't think I
want to go there.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.



 Sat, 23 Jul 2005 18:16:07 GMT   
 Solaris 8 threads: If a routine is Async-Signal-Safe is it also thread Safe?

There is no particular implementation prescribed by POSIX either for "thread
safe" or for "async-signal safe". The POSIX and XSH async-signal safe
functions are also thread-safe, but the async-signal safe functions are
those generally implemented as "pure syscalls" (entirely within the
kernel), and therefore user-mode synchronization (or signal masks) are
completely irrelevant. If they're NOT implemented as syscalls, you'll
generally have a problem because it's not easy to write user-mode code
that's both async-signal safe AND thread-safe unless the routine can be
made fully reentrant.

Few, if any, of the POSIX and XSH async-signal safe functions can be made
fully reentrant, because they generally affect shared data: for example
open, close, read, and write modify file descriptors, and that modification
needs to be synchronized.

In any case, this is diverging from the topic. The original question
regarded an interpretation of terminology. While the question specifically
referenced Solaris man pages, it wasn't at all clear what the INTENT of the
question might be, so a general explanation seemed in order. I said that I
don't have the exact Solaris definition (which is related to but not
identical to the POSIX definition) handy. I also said that in general one
could expect that async-signal safe was also [thread] safe, but gave a
cautionary example of how this isn't necessarily so.

--
/--------------------[ David.Buten...@hp.com ]--------------------\
| Hewlett-Packard Company       Tru64 UNIX & VMS Thread Architect |
|     My book: http://www.awl.com/cseng/titles/0-201-63392-2/     |
\----[ http://homepage.mac.com/dbutenhof/Threads/Threads.html ]---/



 Sat, 23 Jul 2005 20:30:27 GMT   
 Solaris 8 threads: If a routine is Async-Signal-Safe is it also thread Safe?
Hi!

You're not alone. There's at least two ofunctions (tcflush(3) and
tcdrain(3)) that are marked as "MT-Safe, and Async-Signal-Safe"
(original spelling).

On the other hand, the following excerpt from the attributes(5) man
page:

               Async-Signal-Safe  refers  to  particular  library
               routines  that  can be safely called from a signal
               handler.  A thread that  is  executing  an  Async-
               Signal-Safe  routine will not deadlock with itself
               if interrupted by a signal.  Signals  are  only  a
               problem for MT-Safe routines that acquire locks.

               Signals are disabled when locks  are  acquired  in
               Async-Signal-Safe routines. This prevents a signal
               handler that might  acquire  the  same  lock  from
               being  called.

and in particular its third statement, may be interpreted as a hint at
that Async-Signal-Safe are indeed MT-Safe, and thus Safe, because:

                                                      An  MT-Safe
               library  must  permit  a  reasonable   amount   of
               concurrency. (This definition's purpose is to give
               precision to what  is  meant  when  a  library  is
               described  as  Safe.   The  definition  of  a Safe
               library does not specify if the  library  supports
               concurrency.   The  MT-Safe  definition  makes  it
               clear that the library is Safe, and supports  some
               concurrency.   This clarifies the Safe definition,
               which can mean anything from being single threaded
               to being any degree of multithreaded.)

Now, what amount of concurrency is supposed to be supported by close(2)
that is Async-Signal-Safe? The ability to be closing more than one file
at a time using different threads? Perhaps.

So, with the jury still out, I'd advise you to consider these two
attributes orthogonal to be on the safe side.

Best regards.

Alexander

--
Dr Alexander Supalov
Senior Software Engineer
--------------------------------------------------------------------
//// pallas / A Member of the ExperTeam Group
Pallas GmbH / Hermuelheimer Str. 10 / 50321 Bruehl / Germany
Alexander.Supa...@pallas.com / www.pallas.com
Tel +49-2232-1896-34 / Fax +49-2232-1896-29
--------------------------------------------------------------------



 Sun, 24 Jul 2005 23:30:32 GMT   
 
   [ 12 post ] 

Similar Threads

1. Delivery of signals when thread not async safe

2. Thread-safe and Signal-safe

3. mmap, thread-safe, and signal-safe

4. localtime in Solaris 9 is not thread safe?

5. Thread safe alternative to system() on Solaris 2.6?

6. Thread-safe code under Solaris JDK 1.1+

7. Is errno thread safe on solaris ??

8. Thread-safe C libraries in Solaris?

9. Why is localtime_r() not ASYNC-SIGNAL-safe ?


 
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software