I omitted to say: I run qnx 6.4.1

> I have a sporadic failing pthread_spin_init() with errno=EBUSY, where the 
> spinner is located in a piece of ram to be shared with another process 
> (PTHREAD_PROCESS_SHARED flag is used, for this reason).

hi, it's me again

I took a look to the kernel sources, to find out possible ideas, and it seems that it can fail only for a couple of 
reasons, here:

function: synchash_add()
module: services/system/ker/nano_sync.c

reason 1)
_scalloc() can't find new memory for the secondary hash table.
This seems too strange to me: why always (and only) in front of my pthread_spin_init()?

reason 2)
the physical address of my pthread_spinlock_t object leads to something already present in the hash table.
This sounds impossible since I'm initializing the pthread_spinlock_t into memory just allocated from the kernel (I call 
mmap64() directly, asking for physically contiguous ram), so noone else can hold that memory page.

In fact, trying to understand the hashing rules, I see that only 23 bits of the physical mutex address are taken into 
account: can this be the probem? For sure I have some pthread_spinlock_t in other running processes...

thanks for any help!
Davide

Another hypothesis

when a pthread_spinlock_t gets initialized with pthread_spin_init(PTHREAD_PROCESS_PRIVATE), does it get automatically 
destroyed if the owner process exits without explicitly calling pthread_spin_destroy()?

If not, this can be an explanation of my problem. And a lack of kernel rensonsibilities ;)

Davide

Sorry, does anyone have an hint or idea for this?

I applied all possible attentions allocating the memory, initilizing the pthread_spin_t and rleasing the memory when 
done, but I still get the init error with EBUSY.

thanks,
Davide