Hi Stephen,
2022-02-24 09:44 (UTC-0800), Stephen Hemminger:
> There seems to be some confusion here:
>pthread_mutex put thread to sleep if contended and on linux are built on
> the futex system call.
>pthread_rwlock are the reader/writer versions of these.
>
> The DPDK has primitives for
Hi Konstantin,
2022-02-24 17:29 (UTC+), Ananyev, Konstantin:
[...]
> > However, DmitryM suggested using Slim Reader-Writer lock (SRW):
> > https://docs.microsoft.com/en-us/windows/win32/sync/slim-reader-writer--srw--locks
> > instead of CRITICAL_SECTION.
> > It seems to be a much better option
On Thu, 24 Feb 2022 17:29:03 +
"Ananyev, Konstantin" wrote:
> Hi Dmitry,
>
> > 2022-02-21 00:56 (UTC+0300), Dmitry Kozlyuk:
> > > 2022-02-09 13:57 (UTC+), Ananyev, Konstantin:
> > > > > > Actually, please scrap that comment.
> > > > > > Obviously it wouldn't work for static variables
Hi Dmitry,
> 2022-02-21 00:56 (UTC+0300), Dmitry Kozlyuk:
> > 2022-02-09 13:57 (UTC+), Ananyev, Konstantin:
> > > > > Actually, please scrap that comment.
> > > > > Obviously it wouldn't work for static variables,
> > > > > and doesn't make much sense.
> > > > > Though few thoughts remain:
>
2022-02-21 00:56 (UTC+0300), Dmitry Kozlyuk:
> 2022-02-09 13:57 (UTC+), Ananyev, Konstantin:
> > > > Actually, please scrap that comment.
> > > > Obviously it wouldn't work for static variables,
> > > > and doesn't make much sense.
> > > > Though few thoughts remain:
> > > > for posix we probab
2022-02-09 13:57 (UTC+), Ananyev, Konstantin:
> > > Actually, please scrap that comment.
> > > Obviously it wouldn't work for static variables,
> > > and doesn't make much sense.
> > > Though few thoughts remain:
> > > for posix we probably don't need an indirection and
> > > rte_thread_mutex c
> > Actually, please scrap that comment.
> > Obviously it wouldn't work for static variables,
> > and doesn't make much sense.
> > Though few thoughts remain:
> > for posix we probably don't need an indirection and
> > rte_thread_mutex can be just typedef of pthread_mutex_t.
> > also for posix we
> On Mon, Feb 07, 2022 at 04:02:54PM +, Ananyev, Konstantin wrote:
> > > Add functions for mutex init, destroy, lock, unlock, trylock.
> > >
> > > Windows does not have a static initializer. Initialization
> > > is only done through InitializeCriticalSection(). To overcome this,
> > > RTE_INIT_
On Mon, Feb 07, 2022 at 04:02:54PM +, Ananyev, Konstantin wrote:
> > Add functions for mutex init, destroy, lock, unlock, trylock.
> >
> > Windows does not have a static initializer. Initialization
> > is only done through InitializeCriticalSection(). To overcome this,
> > RTE_INIT_MUTEX macro
On Tue, Feb 08, 2022 at 02:21:49AM +, Ananyev, Konstantin wrote:
>
>
> > > +
> > > +/**
> > > + * Thread mutex representation.
> >
>
> Actually, please scrap that comment.
> Obviously it wouldn't work for static variables,
> and doesn't make much sense.
> Though few thoughts remain:
> for
> > +
> > +/**
> > + * Thread mutex representation.
> > + */
> > +typedef struct rte_thread_mutex_tag {
> > + void *mutex_id; /**< mutex identifier */
> > +} rte_thread_mutex;
>
> I wonder can't we have something like that instead:
>
> for posix:
> typedef pthread_mutex_t rte_thread_mutex_t
> Add functions for mutex init, destroy, lock, unlock, trylock.
>
> Windows does not have a static initializer. Initialization
> is only done through InitializeCriticalSection(). To overcome this,
> RTE_INIT_MUTEX macro is added to replace static initialization
> of mutexes. The macro calls rte_th
On Wed, Nov 10, 2021 at 05:33:45PM -0800, Narcisa Ana Maria Vasile wrote:
> From: Narcisa Vasile
>
> Add functions for mutex init, destroy, lock, unlock, trylock.
>
> Windows does not have a static initializer. Initialization
> is only done through InitializeCriticalSection(). To overcome this,
13 matches
Mail list logo
