[PATCH] Cygwin: af_unix_spinlock_t: add initializer
Corinna Vinschen
corinna-cygwin@cygwin.com
Fri Jan 11 09:19:00 GMT 2019
On Jan 10 23:20, Ken Brown wrote:
> 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
Done.
Thanks,
Corinna
--
Corinna Vinschen
Cygwin Maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-patches/attachments/20190111/02e068e2/attachment.sig>
More information about the Cygwin-patches
mailing list