Nksingh (None.delete@this.none.non) on January 6, 2020 11:09 pm wrote:
> Michael S (already5chosen.delete@this.yahoo.com) on January 6, 2020 12:59 pm wrote:
> > Gian-Carlo Pascutto (gcp.delete@this.sjeng.org) on January 6, 2020 11:33 am wrote:
> > > Michael S (already5chosen.delete@this.yahoo.com) on January 6, 2020 8:11 am wrote:
> > > > What do you consider "pretty high overhead"?
> > >
> > > I'm talking about size (as explained in the next paragraphs...).
> > >
> > > Allocating a mutex per node causes your Windows handle count to go wild.
> > >
> > > --
> > > GCP
> >
> > Well, I didn't get it that you were talking about size.
> > But yes, I don't know what is "node" in your application, but if it is something
> > relatively small and short-lived and very numerous (like >> 10000) then one
> > new CRITICAL_SECTION object per node does not sound like a good idea.
> > And yes, the first workaround I would consider is a pre-allocated
> > pool of CRITICAL_SECTIONs (say, 256 of them)
> > with pseudo-random mapping of nodes into pool indices. At
> > the first glance, it seems to me like a good solution;
> > certainly better than rolling my own user-mode spinlock. But may be, again, I am overlooking something.
> >
> >
> Assuming you're talking about synchronizing multiple threads in a single Windows process,
> the SRW lock is the size of a pointer and requires no additional memory behind the scenes
> (it uses on-stack data for waiting threads). For cross-process, you're on your own unless
> you want to use a OS mutex that involves a kernel call for acquire and release.
>

Can you point me to explanation of how SRW locks are implemented under the hood?
"No additional memory" is intriguing and right now (still sort of morning here, not the time of day when I am able to think) I can't figure out how they did it.
Or, may be, you could give us a short explanation right here?