Very Computer

by **Wendy Marle** » Sat, 01 Feb 2003 23:37:17

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).

by **Dragan Cvetkovi** » Sat, 01 Feb 2003 23:47:11

> 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).

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

by **David Butenho** » Sun, 02 Feb 2003 03:31:40

> 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).

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.)

--

| 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 ]---/

by **Casper H.S. Di** » Sun, 02 Feb 2003 05:13:00

>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).

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.

by **Casper H.S. Di** » Sun, 02 Feb 2003 05:16:24

>> 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).
>The aforementioned man page mentions close(2) as an counterexample.

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.

by **Dragan Cvetkovi** » Sun, 02 Feb 2003 05:29:45

> >> 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).

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

> 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.)

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

by **Joseph Seig** » Sun, 02 Feb 2003 05:42:10

> > >> 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).

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

> > 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.)

> 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?

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

by **Casper H.S. Di** » Sun, 02 Feb 2003 17:53:26

>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?

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.

by **lgan** » Wed, 05 Feb 2003 08:26:26

Quote:> 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.

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

by **Casper H.S. Di** » Wed, 05 Feb 2003 19:16:07

>> 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.
>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.

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.

by **David Butenho** » Wed, 05 Feb 2003 21:30:27

>> 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.

> 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.

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.

--

| 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 ]---/

by **Alexander Supalo** » Fri, 07 Feb 2003 00:30:32

Hi!

Quote:> 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).

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

Tel +49-2232-1896-34 / Fax +49-2232-1896-29
--------------------------------------------------------------------

Very Computer

Solaris 8 threads: If a routine is Async-Signal-Safe is it also thread Safe?

Solaris 8 threads: If a routine is Async-Signal-Safe is it also thread Safe?

Solaris 8 threads: If a routine is Async-Signal-Safe is it also thread Safe?

Solaris 8 threads: If a routine is Async-Signal-Safe is it also thread Safe?

Solaris 8 threads: If a routine is Async-Signal-Safe is it also thread Safe?

Solaris 8 threads: If a routine is Async-Signal-Safe is it also thread Safe?

Solaris 8 threads: If a routine is Async-Signal-Safe is it also thread Safe?

Solaris 8 threads: If a routine is Async-Signal-Safe is it also thread Safe?

Solaris 8 threads: If a routine is Async-Signal-Safe is it also thread Safe?

Solaris 8 threads: If a routine is Async-Signal-Safe is it also thread Safe?

Solaris 8 threads: If a routine is Async-Signal-Safe is it also thread Safe?

Solaris 8 threads: If a routine is Async-Signal-Safe is it also thread Safe?

Solaris 8 threads: If a routine is Async-Signal-Safe is it also thread Safe?