Prev: Calling library functions in Linux kernel code
Next: Fail-over: how data can be migrated from the failed server?
From: john on 22 Jul 2010 04:41
Geoff Clare wrote:
> john wrote:
>
>> pthread_mutexattr_t hAttr;
>> pthread_mutexattr_init(&hAttr);
>> pthread_mutexattr_settype(&hAttr, PTHREAD_MUTEX_RECURSIVE_NP);
>> pthread_mutexattr_setrobust_np(&hAttr, PTHREAD_MUTEX_ROBUST_NP);
>> pthread_mutexattr_setpshared(&hAttr, PTHREAD_PROCESS_SHARED)
>> pthread_mutex_init((pthread_mutex_t*)m_hMutex, NULL);
>
> The second argument should be &hAttr, not NULL.
>


oops, my bad. I can't believe I missed this one. This was definitely a
mistake but changing it did not fix my problem.

I've been reading around a lot and although you can use mutexes in
shared memory, a lot of people seem to recommend using semaphores. I
guess using them as a boolean type (i.e. only ever letting it be set to
0 or 1) should allow me to have shared memory protection.

I'm still going to try and get the mutex working in the shared memory as
a background task and post back if I find my error :s

Cheers,

John.
From: Daniel Molina Wegener on 22 Jul 2010 09:41
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Mi� 21 Jul 2010 08:06,
Ersek, Laszlo wrote:

> On Wed, 21 Jul 2010, Daniel Molina Wegener wrote:
>
>> Also, for shared memory segments and IPC, assuming that you are sharing
>> the memory segment between 2 or more proccess, POSIX thread mutexes on
>> that case are useless, since you can not see a mutex between two or more
>> process.
>
> This seems to be wrong.
>
>
http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_setpshared.html

Thanks for the link, I'm checking those calls right now :)
The question now is how to identify a mutex between two process,
but on Linux at the pthread_mutex_getpshared(p) manual page
I get:

"if threads of differing processes attempt to operate on such
a mutex, the behavior is undefined. The default value of the
attribute shall be PTHREAD_PROCESS_PRIVATE."

And it was copied from page pointed to POSIX manual page at the
OpenGoup:

"if threads of differing processes attempt to operate on such a
mutex, the behavior is undefined. The default value of the
attribute shall be PTHREAD_PROCESS_PRIVATE."

>
> lacos

Best regards,
- --
Daniel Molina Wegener <dmw [at] coder [dot] cl>
System Programmer & Web Developer
Phone: +56 (2) 979-0277 | Blog: http://coder.cl/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCgAGBQJMSEqQAAoJEHxqfq6Y4O5N6yYQALVsGorAyCJcciYpkldAw1CN
9bPy3FMNBd+88axHDdiFStQ4HM7PDE3YqZ3uVT1F25srgbT3CrRnIR3H3PoFb8ou
Ca91VpPFz1gRwU7/31XOKdO6QhHeDKVvRgmTAnhmuwqFQ+kEy9T0y65jQGGGHt1S
m8QIhnRBvKnjlVlSbbsWT+O/K7bOEB0yQkP1MDAEgAbhn61gOPmCTGyx58xoXEnw
2FqKqNmaUxihtHyd/EkvPc6CrY9DMggCN/YzxQjY+VkYI/9ersEP4EKLcP92L7K2
ygoriXA61uJTuul3xhb4ardhd1O0GBUMpQ8pMdOw8K4bKUs8NYpuU7Slh45C8kaa
wj4t7He5usZlSZE1ybu7p3mA68G2wfmfEji9zS2abByQ3pBgqssiUGkUWLIyv86y
PUVJfTpX8kY4qSFw/90JYNCxj4MK6OxwCGxoynqOeMXhHrMfZrRbTEXGnNybDXOo
9CIr9VQbQUWI0/yd7EUog4dq3fanjDxgIWCcp1ObCGf9E2EiNIn1cuLWT6GTJWtj
h2omTun5OK8d9qs/GJgPde3p4HyivN1pcVWXniXoOIoQEBVmf4Hg+KdNy2Aspxvg
T8dZCSP3tvOpVprvfZ0BpJcSUoKTl3B5o75fFMUxyjso70HlthB1z2pqDEe5nnaZ
EltQlPTthp/V4Pq/MXTw
=nVn9
-----END PGP SIGNATURE-----

From: David Schwartz on 22 Jul 2010 14:18
On Jul 22, 6:41 am, Daniel Molina Wegener <d...(a)coder.cl> wrote:

> The question now is how to identify a mutex between two process,
> but on Linux at the pthread_mutex_getpshared(p) manual page
> I get:
>
>   "if threads of differing processes attempt to operate on such
>    a mutex, the behavior is undefined. The default value of the
>    attribute shall be PTHREAD_PROCESS_PRIVATE."
>
>   And it was copied from page pointed to POSIX manual page at the
> OpenGoup:
>
>    "if threads of differing processes attempt to operate on such a
>     mutex, the behavior is undefined. The default value of the
>     attribute shall be PTHREAD_PROCESS_PRIVATE."

Right, but "such a mutex" means one specifically not set to be process
shared.

""If the process-shared attribute is PTHREAD_PROCESS_PRIVATE, the
mutex shall only be operated upon by threads created within the same
process as the thread that initialized the mutex; if threads of
differing processes attempt to operate on such a mutex, the behavior
is undefined.""

The rest of us are specifically talking about mutexes that *DON'T*
have the process-shared attribute set to PTHREAD_PROCESS_PRIVATE.

DS
From: Ersek, Laszlo on 22 Jul 2010 15:32
On Thu, 22 Jul 2010, john wrote:

> Geoff Clare wrote:
>> john wrote:
>>
>>> pthread_mutexattr_t hAttr;
>>> pthread_mutexattr_init(&hAttr);
>>> pthread_mutexattr_settype(&hAttr, PTHREAD_MUTEX_RECURSIVE_NP);
>>> pthread_mutexattr_setrobust_np(&hAttr, PTHREAD_MUTEX_ROBUST_NP);
>>> pthread_mutexattr_setpshared(&hAttr, PTHREAD_PROCESS_SHARED)
>>> pthread_mutex_init((pthread_mutex_t*)m_hMutex, NULL);
>>
>> The second argument should be &hAttr, not NULL.

> oops, my bad. I can't believe I missed this one. This was definitely a
> mistake but changing it did not fix my problem.

(Most probably not the cause of your problem, but still, I find it
interesting in general:)

How does one guarantee the correct alignment of mutex objects in shared
memory, portably?

Thanks,
lacos
From: Scott Lurndal on 22 Jul 2010 15:59
"Ersek, Laszlo" <lacos(a)caesar.elte.hu> writes:
>On Thu, 22 Jul 2010, john wrote:
>
>> Geoff Clare wrote:
>>> john wrote:
>>>
>>>> pthread_mutexattr_t hAttr;
>>>> pthread_mutexattr_init(&hAttr);
>>>> pthread_mutexattr_settype(&hAttr, PTHREAD_MUTEX_RECURSIVE_NP);
>>>> pthread_mutexattr_setrobust_np(&hAttr, PTHREAD_MUTEX_ROBUST_NP);
>>>> pthread_mutexattr_setpshared(&hAttr, PTHREAD_PROCESS_SHARED)
>>>> pthread_mutex_init((pthread_mutex_t*)m_hMutex, NULL);
>>>
>>> The second argument should be &hAttr, not NULL.
>
>> oops, my bad. I can't believe I missed this one. This was definitely a
>> mistake but changing it did not fix my problem.
>
>(Most probably not the cause of your problem, but still, I find it
>interesting in general:)
>
>How does one guarantee the correct alignment of mutex objects in shared
>memory, portably?

The processor ABI requires objects to be allocated at specified alignments.

The mutex object is generally specified as a struct type, which IIRC is
required to be aligned at a boundary consistent with the largest alignment
required by any member (typically an 8-byte boundary for the x86_64 ABI).

Therefore, the compiler will _align_ the mutex object at the correct alignment
boundary.

The developers of the pthread library and processor ABI also take care to ensure
that any field in the structure which may be the target of a lock prefix
(on Intel/AMD architectures) never crosses a cache line boundary (a split lock).

Split-locks are bad, bad, bad since they generate global bus locks (a lock
prefix on a memory reference contained entirely within a single 64-byte cache
line simply requires exclusive access by the cache coherency protocol and doesn't
need to stop the entire system with a global bus lock; the same locked reference
to a memory access that spans two cache lines requires a system-wide _global_
bus lock that serializes _all_ memory references in the system).

scott
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Calling library functions in Linux kernel code
Next: Fail-over: how data can be migrated from the failed server?