List of Synchronous and Asynchronous Linux/Posix Signals

Are POSIX signals resulting from a fault generated synchronously or asynchronously?

The two scenarios are different, and 'synchronous' vs. 'asynchronous' is determined at the time of generation.

To rephrase your second question a bit, you ask, "can a synchronously-generated SIGILL attributed to a particular thread be delivered to a different thread in the same process?"

No. A synchronously-generated signal can only be delivered to the thread that caused it. (2.4.1 Signal Generation and Delivery)

Now as a caveat and as mentioned in another answer, normal signal masking semantics do not apply to some synchronously-generated signals. In particular, as the specs pthread_sigmask and sigprocmask say, "[i]f any of the SIGFPE, SIGILL, SIGSEGV, or SIGBUS signals are generated while they are blocked, the result is undefined, unless the signal was generated [asynchronously]". (emphasis added)

What is the status of POSIX asynchronous I/O (AIO)?

Network I/O is not a priority for AIO because everyone writing POSIX network servers uses an event based, non-blocking approach. The old-style Java "billions of blocking threads" approach sucks horribly.

Disk write I/O is already buffered and disk read I/O can be prefetched into buffer using functions like posix_fadvise. That leaves direct, unbuffered disk I/O as the only useful purpose for AIO.

Direct, unbuffered I/O is only really useful for transactional databases, and those tend to write their own threads or processes to manage their disk I/O.

So, at the end that leaves POSIX AIO in the position of not serving any useful purpose. Don't use it.

when multi-thread program receive a SIGPIPE signal because send, which thread would handle the signal in linux?

Asynchronous signals like SIGPIPE can go to any thread. You can use signal masks to limit which of the threads is eligible.

Synchronous signals like SIGSEGV will be delivered on the thread that caused them.

Is this a POSIX-compliant implementation for handling signals such as SIGFPE, SIGSEGV, etc. in a multithreaded program?

No, it is not POSIX-compliant. Defined signal-handler behavior is especially restricted for multi-threaded programs, as described in the documentation of the signal() function:

If the process is multi-threaded [...] the behavior is undefined if
the signal handler refers to any object other than errno with
static storage duration other than by assigning a value to an object
declared as volatile sig_atomic_t [...].

Your signal handler's proposed access to the semaphore therefore would cause the program's behavior to be undefined, regardless of which function you use. Your handler could conceivably create a local semaphore and manipulate it with async-signal safe functions, but that would not serve a useful purpose. There is no conforming way for it to access a semaphore (or most any other object) with wider scope.

Is asynchronous and synchronous I/O OS independent?

This is a very broad question, and the answer depends on the context.

For I/O between the CPU and other peripherals, it depends on the hardware I/O interface. Most devices in your system use an synchronous interface, such as the PCI-express bus. Other devices (typically slower performing ones) can use an asynchronous interface to communicate, such as the serial port.

If your question is about inter-process communications within an operating system, the OS typically provides both synchronous or asynchronous methods. This is because certain applications specifically requires synchronous communications, while others requires specifically needs asynchronous communications. You can think of the following question instead: is it crucial for your program to wait for a message to be sent or received before doing anything else, or can you ignore them for now and check up on them later?

Synchronous communications require the sender to wait and do nothing until the message has been successfully delivered by the recipient. The same applies for receiving a message: the receiving process will wait and do nothing until the intended message has been received.

In asynchronous communications, the sender will send out a message, and then proceed with other tasks without waiting. The receiver also do not need to block-wait until a message arrives. It will periodically check to see if any messages are available.

Will signals be delivered to a program blocked on POSIX semaphore?

[too long for a comment]

Accessing var from inside the signal handler invokes undefined behaviour (at least for a POSIX conforming system).

From the related POSIX specification:

[...] if the process is single-threaded and a signal handler is executed [...] the behavior is undefined if the signal handler refers to any object [...] with static storage duration other than by assigning a value to an object declared as volatile sig_atomic_t [...]

So var shall be defined:

volatile sig_atomic_t var;

The busy waiting while-loop, can be replaced by a single call to a blocking pause(), as it will return on reception of the signal.

From the related POSIX specification:

The pause() function shall suspend the calling thread until delivery of a signal whose action is either to execute a signal-catching function or to terminate the process.

Using pause(), btw, will make the use of any global flag like var redundant, to not say needless.

How to make a function async-signal-safe?

You can use fcntl() as an alternative to flock().