Scribd
Upload
124 views4 pages

2.6 POSIX Vs System V

The document compares System V and POSIX IPC mechanisms, highlighting their differences in interfaces, features, and usage. System V, introduced in 1983, includes various IPC mechanisms but lacks thread safety, while POSIX offers a more modern, thread-safe alternative with additional features. Although System V is still relevant for legacy applications, POSIX is increasingly preferred for new developments due to its simplicity and portability.

Uploaded by

parasprrm
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
124 views4 pages

2.6 POSIX Vs System V

The document compares System V and POSIX IPC mechanisms, highlighting their differences in interfaces, features, and usage. System V, introduced in 1983, includes various IPC mechanisms but lacks thread safety, while POSIX offers a more modern, thread-safe alternative with additional features. Although System V is still relevant for legacy applications, POSIX is increasingly preferred for new developments due to its simplicity and portability.

Uploaded by

parasprrm
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

2.

6 POSIX vs System V
2.6.1 Comparison Between System V and POSIX IPC
2.6.1.1 Introduction

System V: Introduced by AT&T in 1983, System V added three new forms of Inter-
Process Communication (IPC) mechanisms: message queues, shared memory, and
semaphores.
POSIX: Defined by the IEEE as the Portable Operating System Interface standard,
POSIX specifies application programming interfaces (APIs) for portability. It includes
support for all three IPC mechanisms introduced by System V.

2.6.1.2 IPC Mechanisms

System V: Covers a wide range of IPC mechanisms, including pipes, named pipes,
message queues, signals, semaphores, shared memory, sockets, and Unix domain
sockets.
POSIX: Shares the same basic concepts as System V but differs in its interface. It also
includes additional features such as thread synchronization and notification mechanisms.

2.6.1.3 Shared Memory Interface

System V: Uses the following system calls for shared memory:


shmget() , shmat() , shmdt() , shmctl()
POSIX: Uses a different set of calls for shared memory:
shm_open() , mmap() , shm_unlink()

2.6.1.4 Message Queue Interface

System V: Provides the following calls for message queues:


msgget() , msgsnd() , msgrcv() , msgctl()
POSIX: Uses a different set of calls for message queues:
mq_open() , mq_send() , mq_receive() , mq_unlink()

2.6.1.5 Semaphore Interface

System V: Provides the following calls for semaphores:


semget() , semop() , semctl()
POSIX: Offers two types of semaphores:
Named Semaphores: sem_open() , sem_close() , sem_unlink() , sem_post() ,
sem_wait() , sem_trywait() , sem_timedwait() , sem_getvalue()
Unnamed (Memory-based) Semaphores: sem_init() , sem_post() ,
sem_wait() , sem_getvalue() , sem_destroy()

2.6.1.6 Identification of IPC Objects

System V: Uses keys and identifiers to identify IPC objects.


POSIX: Uses names and file descriptors to identify IPC objects.

2.6.1.7 Monitoring and Notifications

System V: Does not provide built-in monitoring or notification features for message
queues.
POSIX:
Message queues can be monitored using APIs like select() , poll() , and
epoll() .
Offers notification features for message queues, such as mq_notify() .

2.6.1.8 Attribute Management

System V: Provides the msgctl() call to manage message queue attributes.


POSIX: Offers functions like mq_getattr() and mq_setattr() to access or modify
message queue attributes.

2.6.1.9 Thread Safety and Synchronization

System V: Does not include thread synchronization features.


POSIX: Is multi-thread safe and includes thread synchronization mechanisms such as
mutex locks, condition variables, and read-write locks.

2.6.1.10 Shared Memory Operations

System V: Requires system calls like shmctl() and commands like ipcs and ipcrm
to perform status and control operations.
POSIX: Shared memory objects can be examined and manipulated using system calls
like fstat() and fchmod() .

2.6.1.11 Shared Memory Size

System V: The size of a shared memory segment is fixed at the time of creation using
shmget() .
POSIX: Allows resizing of shared memory objects using ftruncate() . The mapping can
then be recreated using munmap() and mmap() or the Linux-specific mremap() .

This expanded comparison highlights the key differences and similarities between System V
and POSIX IPC mechanisms, making it easier to understand their respective features and
use cases.

2.6.2 System V vs POSIX IPC: Usage and Obsolescence


2.6.2.1 Popularity and Usage
System V IPC and POSIX IPC are both widely used, but their adoption depends on the
context and requirements of the project:

1. System V IPC:
System V IPC has been around since 1983 and is still widely implemented in many
systems, especially for legacy applications.
It is commonly used in older Unix-based systems and applications that rely on its
specific features, such as the SEM_UNDO flag for semaphores or the ability to deliver
messages by mtype in message queues.
Despite its age, System V IPC remains relevant in environments where backward
compatibility is critical.
2. POSIX IPC:
POSIX IPC is newer and was designed to address some of the limitations of System
V IPC. It offers a simpler, more consistent interface and better integration with the
Unix file model.
POSIX IPC is thread-safe and includes features like message queue notifications
( mq_notify() ) and the ability to monitor message queues using select() ,
poll() , or epoll() .
It is increasingly preferred for new development due to its portability and modern
design.

System V IPC is not obsolete but is considered outdated in some contexts. Here are the key
points:

1. Legacy Support:
System V IPC is still supported in most Unix-like operating systems, including Linux,
because many legacy applications depend on it.
It is unlikely to be removed entirely due to its widespread use in older systems.
2. Limitations:
System V IPC is not thread-safe, which makes it less suitable for modern multi-
threaded applications.
Its interface is considered more complex and less intuitive compared to POSIX IPC.
3. POSIX as the Future:
POSIX IPC is seen as the future standard for inter-process communication due to its
simplicity, portability, and alignment with modern programming practices.
Many vendors and developers are moving toward POSIX IPC for new projects, but
System V IPC remains in use for maintaining older systems.

You might also like