On 09/05/18(Wed) 14:19, Paul Irofti wrote:
> > [...]
> > I'd prefer if we could teach each other how stuff really work :o)
>
> Frankly someone else will have to enlighten me (or us) if we really
> need to do this.
That's what guenther@ and visa@ did. So I believe you should move
forward and comm
On Wed, May 09, 2018 at 12:43:14PM +0200, Martin Pieuchot wrote:
> On 09/05/18(Wed) 13:07, Paul Irofti wrote:
> > On Wed, May 09, 2018 at 11:33:06AM +0200, Martin Pieuchot wrote:
> > > On 09/05/18(Wed) 11:43, Paul Irofti wrote:
> > > [...]
> > > Then the writer uses atomic operations to increment/
On 09/05/18(Wed) 13:07, Paul Irofti wrote:
> On Wed, May 09, 2018 at 11:33:06AM +0200, Martin Pieuchot wrote:
> > On 09/05/18(Wed) 11:43, Paul Irofti wrote:
> > [...]
> > Then the writer uses atomic operations to increment/decrement `waitcount'
> > but is it enough to have the reader, see the upda
On Wed, May 09, 2018 at 11:33:06AM +0200, Martin Pieuchot wrote:
> On 09/05/18(Wed) 11:43, Paul Irofti wrote:
> > > [...]
> > > I'm saying that increasing/decreasing `waitcount' now serves a single
> > > purpose: the check in sem_destroy(). However with your implementation
> > > this check is rac
On 09/05/18(Wed) 11:43, Paul Irofti wrote:
> > [...]
> > I'm saying that increasing/decreasing `waitcount' now serves a single
> > purpose: the check in sem_destroy(). However with your implementation
> > this check is racy and adds two atomic operation on top of every
> > syscall. So my questio
> > > > new file mode 100644
> > > > index 000..e5c8015d27c
> > > > --- /dev/null
> > > > +++ lib/librthread/rthread_sem_atomic.c
> > >
> > > I'm not fan of the _atomic suffix. What about rthread_semaphore.c?
> >
> > I am not set on the name, but I do think rthread_semaphore is not a goo
On 07/05/18(Mon) 14:01, Paul Irofti wrote:
> > > > > The reason we need this is to make semaphores safe for asynchronous
> > > > > signals.
> >
> > Could you describe with words what is currently broken and how the
> > version below fixes it?
>
> POSIX dictates that sem_post() needs to be async-s
> > > > The reason we need this is to make semaphores safe for asynchronous
> > > > signals.
>
> Could you describe with words what is currently broken and how the
> version below fixes it?
POSIX dictates that sem_post() needs to be async-safe here[0] and is
thus included in the list of safe func
On 30/04/18(Mon) 14:36, Paul Irofti wrote:
> On Sat, Apr 28, 2018 at 07:40:38PM +0300, Paul Irofti wrote:
> > On Sun, Apr 22, 2018 at 03:34:45PM +0300, Paul Irofti wrote:
> > > Here is a new semaphore implementation that uses atomic operations,
> > > where available, and futexes for locking.
I'm
On Sat, Apr 28, 2018 at 07:40:38PM +0300, Paul Irofti wrote:
> On Sun, Apr 22, 2018 at 03:34:45PM +0300, Paul Irofti wrote:
> > Hi,
> >
> > Here is a new semaphore implementation that uses atomic operations,
> > where available, and futexes for locking.
> >
> > The reason we need this is to make
On Sun, Apr 22, 2018 at 03:34:45PM +0300, Paul Irofti wrote:
> Hi,
>
> Here is a new semaphore implementation that uses atomic operations,
> where available, and futexes for locking.
>
> The reason we need this is to make semaphores safe for asynchronous
> signals.
>
>
> All posixsuite tests (
Hi,
Here is a new semaphore implementation that uses atomic operations,
where available, and futexes for locking.
The reason we need this is to make semaphores safe for asynchronous
signals.
All posixsuite tests (semaphore and sigaction) pass with this.
They do not with our current implementat
12 matches
Mail list logo
