[PATCH] Cygwin: af_unix_spinlock_t: add initializer
Ken Brown
kbrown@cornell.edu
Thu Jan 10 23:20:00 GMT 2019
On 1/10/2019 3:16 PM, Corinna Vinschen wrote:
> On Jan 10 18:36, Ken Brown wrote:
>> On 1/10/2019 1:02 PM, Corinna Vinschen wrote:
>>> On Jan 10 17:56, Ken Brown wrote:
>>>> Also fix a typo.
>>>> ---
>>>> winsup/cygwin/fhandler.h | 3 ++-
>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/winsup/cygwin/fhandler.h b/winsup/cygwin/fhandler.h
>>>> index d02b9a913..7e460701c 100644
>>>> --- a/winsup/cygwin/fhandler.h
>>>> +++ b/winsup/cygwin/fhandler.h
>>>> @@ -832,9 +832,10 @@ class fhandler_socket_local: public fhandler_socket_wsock
>>>> /* Sharable spinlock with low CPU profile. These locks are NOT recursive! */
>>>> class af_unix_spinlock_t
>>>> {
>>>> - LONG locked; /* 0 oder 1 */
>>>> + LONG locked; /* 0 or 1 */
>>>
>>> Huh.
>>>
>>>> public:
>>>> + af_unix_spinlock_t () : locked (0) {}
>>>
>>> Why do we need that? The spinlock is created as part of a shared mem
>>> region which gets initialized to all zero, no? Or do you plan to use it
>>> outside of this scenario?
>>
>> At the moment I'm using it in the new FIFO code, and I'm not sure yet whether it
>> will eventually be in shared memory. (Until I get things working, I'm
>> postponing thinking about whether I need shared memory.)
>>
>> Would it be better to use some other kind of spinlock until I know for sure that
>> I need shared memory? My only reason for choosing af_unix_spinlock_t is that I
>> was copying code from fhandler_socket_unix, and this saved me the trouble of
>> learning about other kinds of spinlocks.
>
> The above patch shouldn't hurt in the least since it's not used anyway
> when allocating the shared mem region used by the AF_UNIX socket code.
> If it helps you, I can push it, no problem.
>
> Just make sure this spinlock is the right thing for you. The idea here
> was to have a fast, sharable(*) lock without context switching, only
> guarding small code blocks which don't hang due to resource starving.
>
> If you have to guard more complex code chunks, it might be better to
> use a kernel locking object like mutex or semaphore.
>
>
> So, push or no push?
Please push. Thanks.
Ken
More information about the Cygwin-patches
mailing list