This is the mail archive of the cygwin-patches mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Cygwin: af_unix_spinlock_t: add initializer


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?


Corinna


(*) Originally I thought slim R/W locks are nice for unix sockets...
    until I realised they are not sharable.  Reading MSDN helped :}

-- 
Corinna Vinschen
Cygwin Maintainer

Attachment: signature.asc
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]