What is going on with IPC in linux?

Hano · 08-04-2005, 05:14 PM

Heyo,

yesterday, trying to get a basic inter process shared buffer to work on my RH9 i realized that there is a lot of non-trivial issues with this going on. sem_open and sem_init for inter process send messages of "function not implemented". Can anyone explain me why my linux box doesn't seem to support POSIX calls?

foo_bar_foo · 08-04-2005, 07:44 PM

lets see in my /usr/include/semaphore.h

Code:

/* Initialize semaphore object SEM to VALUE.  If PSHARED then share it
   with other processes.  */
extern int sem_init (sem_t *__sem, int __pshared, unsigned int __value)
     __THROW;
/* Free resources associated with semaphore object SEM.  */
extern int sem_destroy (sem_t *__sem) __THROW;

/* Open a named semaphore NAME with open flags OFLAG.  */
extern sem_t *sem_open (__const char *__name, int __oflag, ...) __THROW;

/* Close descriptor for named semaphore SEM.  */
extern int sem_close (sem_t *__sem) __THROW;

/* Remove named semaphore NAME.  */
extern int sem_unlink (__const char *__name) __THROW;

/* Wait for SEM being posted.

   This function is a cancellation point and therefore not marked with
   __THROW.  */
extern int sem_wait (sem_t *__sem);

#ifdef __USE_XOPEN2K
/* Similar to `sem_wait' but wait only until ABSTIME.

   This function is a cancellation point and therefore not marked with
   __THROW.  */
extern int sem_timedwait (sem_t *__restrict __sem,
			  __const struct timespec *__restrict __abstime);
#endif

/* Test whether SEM is posted.  */
extern int sem_trywait (sem_t *__sem) __THROW;

/* Post SEM.  */
extern int sem_post (sem_t *__sem) __THROW;

/* Get current value of SEM and store it in *SVAL.  */
extern int sem_getvalue (sem_t *__restrict __sem, int *__restrict __sval)
     __THROW;

Hano · 08-04-2005, 07:47 PM

For example, Rh9 Glibc is version 2.3.2.
http://people.redhat.com/~drepper/po...tml#SEMAPHORES

according to this, glibc >=2.3 has full support of inter process semaphores.

So when i try out this code:
http://rafb.net/paste/results/DpMOGz83.html

it gives an error saying "sem open: function not implemented"

What is going on?

foo_bar_foo · 08-04-2005, 11:57 PM

like i said earlier i'm not sure what you are refering to
compile with
g++ -c SCUM_Shm.cpp
g++ -c shm_test.cpp
g++ -o shm_test shm_test.o SCUM_Shm.o -lpthread

of course you get

Code:

SCUM_Shm.o(.text+0xd6): In function `SCUM_SharedMemory::attach(char const*, int)':
: undefined reference to `shm_open'
SCUM_Shm.o(.text+0xfb): In function `SCUM_SharedMemory::attach(char const*, int)':
: undefined reference to `shm_open'
SCUM_Shm.o(.text+0x3a5): In function `SCUM_SharedMemory::detach()':
: undefined reference to `shm_unlink'
collect2: ld returned 1 exit status

because in these three places you have mistyped and put shm_open not sem_open and like that

Hano · 08-05-2005, 12:22 AM

Quote:

Originally posted by foo_bar_foo

because in these three places you have mistyped and put shm_open not sem_open and like that

No sorry, shm_open is not a typo of sem_open. shm_open creates or retrieves a shared memory segment, while sem_open is supposed to create or retrieve a shared semaphore (which would be later used to lock access to the shared segment)

also, you need to link with -lrt

foo_bar_foo · 08-05-2005, 01:59 PM

your right it compiled with -lrt
but when i run it it just segfaults

can't really spend the time to debug
something amiss about this thread

i'm sure this stuff works in Linux if you use it correctly
but basically we never use it
we use sys/sem.h instead
for instance initialze semaphores with semctl()
if you are just coming from a unix background
Linux because of the open source nature of the kernel
has no need for "interfaces" that hide the internalls
accept for compatability with legacy code

Hano · 08-05-2005, 06:56 PM

Quote:

Originally posted by foo_bar_foo
your right it compiled with -lrt
but when i run it it just segfaults

can't really spend the time to debug
something amiss about this thread

i'm sure this stuff works in Linux if you use it correctly
but basically we never use it
we use sys/sem.h instead
for instance initialze semaphores with semctl()
if you are just coming from a unix background
Linux because of the open source nature of the kernel
has no need for "interfaces" that hide the internalls
accept for compatability with legacy code

Dude, please don't take wrong the bottom line from my words. Are you high? i know because when i'm high i say things with the same level of coherence as you just said. Pleeease could you rephrase? You are "sure" this stuff works in Linux? but let me make clear that is not comfort what i'm looking for, and i'm truly sorry if i let out that impression. I only need a clear scheme that someone explans to me about how are you supposed to call INTER PROCESS semaphores (yes, yes POSIX, not SySV semaphores) from a Linux (like, ahhmmm... glibc >=2.3 ) remember? i'm in <------- RH9! thats glibc 2.3.2! it's supposed to have Pthreads and all that stuff! reaallly! i neeeed H E L p! please?

Hano · 08-07-2005, 04:00 AM

Ok i "solved" it. The thing is that the CCRMA 2.4 kernel that i was using has NPTL disabled, hence, everything links ok again realtime and pthread libraries, but they dont produce any functionality at kernel level

smallworld · 12-05-2005, 11:01 PM

I have the same problem like you.
Could you tell me how to resolve this problem? thank you