Hello, Samuel
On 2017-03-04 18:45, Samuel Thibault wrote:
Do we really want to keep that list sorted? That makes waking up two
times less expensive, but it makes waiting much more expensive, so
overall it's just the same.
And I'd think that in practice, there is more probability that the
thre
---
kern/gsync.c | 368 +++--
vm/vm_object.h | 14 +++
2 files changed, 244 insertions(+), 138 deletions(-)
diff --git a/kern/gsync.c b/kern/gsync.c
index e70e1199..56d04387 100644
--- a/kern/gsync.c
+++ b/kern/gsync.c
@@ -17,36 +17,61 @@
*/
This patchset modifies the gsync module so that it works with remote tasks.
The idea is to create a temporary kernel mapping when the contents of the
address have to be read (gsync_wait) or written (gsync_wake).
It also implements a basic sleeping lock to replace the simple locks that were
guardin
, Inc.
+ Contributed by Agustina Arzille , 2017.
+
+ This program is free software; you can redistribute it and/or
+ modify it under the terms of the GNU General Public License
+ as published by the Free Software Foundation; either
+ version 2 of the license, or (at your option) any later
On 2017-01-29 21:34, Samuel Thibault wrote:
Agustina Arzille, on Sun 29 Jan 2017 21:11:12 -0300, wrote:
On 2017-01-29 17:44, Samuel Thibault wrote:
>Agustina Arzille, on Sun 29 Jan 2017 16:46:45 -0300, wrote:
>
>There is just one thing I'm a bit afraid of: the code is assuming
On 2017-01-29 17:44, Samuel Thibault wrote:
Agustina Arzille, on Sun 29 Jan 2017 16:46:45 -0300, wrote:
There is just one thing I'm a bit afraid of: the code is assuming that
the only reason why the locker thread is awakened is that it was given
the mutex control. Is that guaranteed?
On 2017-01-28 21:03, Samuel Thibault wrote:
Hello,
Agustina Arzille, on Thu 19 Jan 2017 10:00:32 -0500, wrote:
+/* Atomically compare *PTR with EXP and set it to NVAL if they're
equal.
+ * Evaluates to a boolean, indicating whether the comparison was
successful.*/
+#define atomic_ca
.
+ Contributed by Agustina Arzille , 2017.
+
+ This program is free software; you can redistribute it and/or
+ modify it under the terms of the GNU General Public License
+ as published by the Free Software Foundation; either
+ version 2 of the license, or (at your option) any later version
---
kern/gsync.c | 368 +++--
vm/vm_object.h | 6 +
2 files changed, 236 insertions(+), 138 deletions(-)
diff --git a/kern/gsync.c b/kern/gsync.c
index e70e1199..f389e457 100644
--- a/kern/gsync.c
+++ b/kern/gsync.c
@@ -17,36 +17,61 @@
*/
mutex.c \
kern/list.h \
kern/lock.c \
kern/lock.h \
diff --git a/kern/atomic.h b/kern/atomic.h
new file mode 100644
index ..d80dbb34
--- /dev/null
+++ b/kern/atomic.h
@@ -0,0 +1,35 @@
+/* Copyright (C) 2016 Free Software Foundation, Inc.
+ Contributed by Agustina Arzille , 2017.
+
On 2016-10-31 17:18, Agustina Arzille wrote:
Hello, everyone.
As discussed on IRC, I'm going to relicense what I've contributed in
order
to avoid any potential conflicts. This implies:
- My contributions to gnumach are relicensed under GPLv2.
- My contributions to glibc are relice
Hello, everyone.
As discussed on IRC, I'm going to relicense what I've contributed in
order
to avoid any potential conflicts. This implies:
- My contributions to gnumach are relicensed under GPLv2.
- My contributions to glibc are relicensed under GPLv2.
- My contributions to glibc add-ons (lib
Here's the updated glibc patch, and the patches for mutexes and rwlocks.
The initial patch for libpthread as published in:
http://lists.gnu.org/archive/html/bug-hurd/2016-05/msg00027.html remains the same.
* hurd/hurdlock.h: New file.
* hurd/hurdlock.c: New file.
* hurd/Makefile: Add hurdlock
On 05/22/2016 03:47 AM, Kalle Olavi Niemitalo wrote:
GPLv3-based licenses may be OK for tests (libio/tst-fwrite-error.c)
but I think not for code that gets loaded from glibc to application
processes, unless a license exception applies (intl/plural.c).
There seems to be a similar problem with in
Hello, Samuel,
On 05/20/2016 04:15 AM, Samuel Thibault wrote:
Just a nitpick (but important one since otherwise I'd have to do the
work myself): we need a ChangeLog in the GNU style, i.e. not only the
rationale as you wrote (which is very useful!) but also a description of
the changes themselves
Hello, everyone.
Here are the patches needed to get the ball rolling and finally introduce
gsync-based synchronization objects into our libc. These 2 first patches modify
the internal locks used by glibc and some bits in libpthread that will be
necessary for more complex objects.
There are quite
On 2016-05-13 06:34, Samuel Thibault wrote:
Oh, that reminds me, now that we have gsync, we could add a proper
GSCOPE implementation in tls.h, see i386's implementation.
Yes, that's the remaining use of __swtch_pri I talked about.
However, like I mentioned, it needs help from libpthread, so it
Oops, I screwed up the robust low-level lock implementation. Here's an updated
patch with that fix.
I forgot to mention it in my previous message, but I left some global cthreads
types as they were, even though they could be replaced by plain integers now.
I'm not sure if anyone uses them directl
On 2016-05-10 03:12, Samuel Thibault wrote:
Just to make sure: are you building the debian package, or from our
hurd/glibc.git tree? In the debian package at least, the testsuite
should be going on, and give a regression summary: quite a few tests
are
"expected" to fail. tgmath2 is however no
On 05/08/2016 07:42 PM, Samuel Thibault wrote:
512M is not so much, perhaps use more as Richard suggested.
I did try that, and got farther than before (Thanks, Richard!). On the other
hand, glibc's testsuite failed during math/tgmath2, after a crash. The output
was:
(17916) crashed, signal: {
Hello, Samuel
On 05/06/2016 10:36 AM, Samuel Thibault wrote:
I ran into a lot of troubles to compile glibc, mostly because the filesystem
kept freezing and / or crashing.
That's worrying, and surprising to me since buildds keep building stuff
for days without too many issues. How are you run
Hello, everyone.
Here's the first of the patches to replace spin-locks in glibc with locks based
on gnumach's gsync.
I ran into a lot of troubles to compile glibc, mostly because the filesystem
kept freezing and / or crashing.
I had to modify several makefiles for a few libs because the new loc
Hello, Samuel
On 04/25/2016 09:37 PM, Samuel Thibault wrote:
Well, I wouldn't say so. Our current implementation does yield to other
threads, which is not what is usually done by spin lock implementations:
usually they really spin on the value, without making system calls, so
as to acquire as fa
Hello, Samuel
On 04/24/2016 02:13 PM, Samuel Thibault wrote:
Like I said before, I understand if people are uneasy with a whole new lib,
Well, that can be fine, but I'm sure there will be regressions, not only
conformance-wise, but also ABI-compatibility-wise, and they will be
difficult to spot
Hello, Samuel.
On 04/20/2016 08:23 AM, Samuel Thibault wrote:
Samuel Thibault, on Mon 18 Apr 2016 21:50:16 +0200, wrote:
I also have the implementation for what glibc calls
'low-level lock' i.e. a wrapper around something like futex. That can be
integrated into glibc to replace spin locks where
On 04/18/2016 04:50 PM, Samuel Thibault wrote:
- Instead of creating thread descriptors with malloc, I place them at the
top of the stack.
This might be questionable too. Is the goal just to save the
allocation? I'm not sure it's worth making the code more complex just
for this (think ab
Hello, Samuel,
On 04/17/2016 12:24 PM, Samuel Thibault wrote:
Hello,
Ok, but why not just fixing pthread_mutex_lock & such in our current
libpthread, instead of having yet another implementation? How are we
supposed to handle those three implementations: Neal's, nptl, and yours?
Ideally your
Original Message
Subject: Re: RFC: Lightweight synchronization mechanism for gnumach v3
Date: 2016-04-15 15:13
From: Agustina Arzille
To: Samuel Thibault
On 2016-04-15 15:01, Samuel Thibault wrote:
Agustina Arzille, on Fri 15 Apr 2016 14:59:11 -0300, wrote:
Great! Thanks
On 2016-04-15 13:22, Samuel Thibault wrote:
Hello,
I have commited it, thanks a lot!
Now eager to see the libpthread changes, so we get much more
efficiency,
notably in the contended case :)
Samuel
Great! Thanks a lot, Samuel! :3
Coincidentally, my copyright assignment was just finished,
rn/gsync.c
new file mode 100644
index 000..227df31
--- /dev/null
+++ b/kern/gsync.c
@@ -0,0 +1,412 @@
+/* Copyright (C) 2016 Free Software Foundation, Inc.
+ Contributed by Agustina Arzille , 2016.
+
+ This program is free software; you can redistribute it and/or
+ modify it under the t
On 04/04/2016 04:34 AM, Samuel Thibault wrote:
You can submit that patch to the libc-al...@sourceware.org mailing list
(explaining the rationale etc. alongside), putting rol...@hack.frob.com
and this bug-hurd@gnu.org list in Cc. And we can commit the patch to
the debian libc in parallel.
Done.
Hello, everyone.
It appears that in GNU/Hurd, memory mappings obtained by 'mmap' with MAP_SHARED
and MAP_ANON as its flags are not being inherited by children processes.
Here's a simple program that illustrates the issue:
===
#include
#include
#include
#include
On 04/03/2016 06:27 AM, Samuel Thibault wrote:
So the fix would be just to remove the whole
if ((flags & (MAP_TYPE|MAP_INHERIT)) == MAP_ANON
block?
Yes, that seems do the trick.
You can submit that patch to the libc-al...@sourceware.org mailing list
(explaining the rationale etc. alongsid
Hello, everyone.
It appears that memory mappings obtained by 'mmap' with MAP_SHARED
and MAP_ANON as its flags are not being inherited by children processes.
Here's a simple program that illustrates the issue:
===
#include
#include
#include
#include
int main (vo
On 03/30/2016 08:58 PM, Samuel Thibault wrote:
Ok, I hadn't understood what you meant. Actually, you perhaps
don't even need to lock the map before calling vm_map_lookup: does
gsync_fill_wait really need to do the valid_access_p() call itself? We
can make functions call gsync_fill_wait, then lo
Hello, Samuel.
On 03/30/2016 08:07 PM, Samuel Thibault wrote:
For shared gsync objects, I'm using vm_map_lookup to find out the
vm object and offset. The problem is that said function expects the map
to be unlocked
Really?
It starts with locking it, and finishes with unlocking it, and the lock
Hello, Samuel
On 03/28/2016 06:29 PM, Samuel Thibault wrote:
Agustina Arzille, on Fri 04 Mar 2016 11:32:10 -0300, wrote:
+#define GSYNC_NBUCKETS 512
+static struct gsync_hbucket gsync_buckets[GSYNC_NBUCKETS];
I'm wondering whether we could want to have buckets per task too? What
does
As promised, here's the patch to avoid the aforementioned alloca bugs.
It's a bit of an overkill, imo, but it does support ridiculously long
command-line arguments =D
For most practical issues, the fix posted in
http://lists.gnu.org/archive/html/bug-hurd/2016-03/msg00086.html
should be enough.
d
On 2016-03-15 15:02, Samuel Thibault wrote:
Agustina Arzille, on Tue 15 Mar 2016 14:57:19 -0300, wrote:
That's not what I meant. Stack overflow is clearly very unlikely, if
not
impossible. What I meant about 'dangerous' is the fact that alloca is
being
used inside the list of
Hello, Samuel.
On 2016-03-15 13:31, Samuel Thibault wrote:
Justus Winter, on Tue 15 Mar 2016 14:39:00 +0100, wrote:
Quoting Agustina Arzille (2016-03-15 14:11:27)
> Hello, everyone.
>
> I was browsing some gnumach source files, and noticed some dangerous use
> of the gcc builtin
Hello, Justus,
On 2016-03-15 10:39, Justus Winter wrote:
Hi,
Quoting Agustina Arzille (2016-03-15 14:11:27)
Hello, everyone.
I was browsing some gnumach source files, and noticed some dangerous
use
of the gcc builtin 'alloca'. In the file kern/bootstrap.c, lines 212
and
228, w
Hello, everyone.
I was browsing some gnumach source files, and noticed some dangerous use
of the gcc builtin 'alloca'. In the file kern/bootstrap.c, lines 212 and
228, we have the following statement:
memcpy (alloca (len), ...)
This is dangerous because alloca works by adjusting the stack point
ndex 000..12398ab
--- /dev/null
+++ b/kern/gsync.c
@@ -0,0 +1,381 @@
+/* Copyright (C) 2016 Free Software Foundation, Inc.
+ Contributed by Agustina Arzille , 2016.
+
+ This program is free software; you can redistribute it and/or
+ modify it under the terms of the GNU General Public Licens
On 02/28/2016 06:32 PM, Samuel Thibault wrote:
Hello,
Agustina Arzille, on Sun 28 Feb 2016 14:22:03 -0300, wrote:
Here's a rough comparison of how locking is implemented in libpthread,
and the futex prototype I posted.
Did you make measurements? It'd be interesting to post them her
On 02/28/2016 02:59 PM, Richard Braun wrote:
On Sat, Feb 27, 2016 at 10:53:12PM -0300, Agustina Arzille wrote:
Hello, everyone.
Here's a patch for gnumach that implements a lightweight synchronization
mechanism. It can be used as a basis to build many higher-level objects like
mu
On 02/28/2016 02:01 PM, Justus Winter wrote:
Hi :)
thanks for your prototype. I cannot comment on the primitive you
implemented because I'm lacking the expertise, however
Quoting Agustina Arzille (2016-02-28 02:53:12)
I've tested it in many scenarios, and seems to work fine. I'
As a followup, here's how one would use gsync to implement something akin to
Linux futexes.
===
#include
#include
/* This bit signals that the lock is being held. The rest of
* the word tells us how many waiters there are. */
#define BIT31 (1U << 31)
#define at
k : task_t;
+ addr : vm_offset_t;
+ val : unsigned;
+ flags : int);
diff --git a/kern/gsync.c b/kern/gsync.c
new file mode 100644
index 000..0a05054
--- /dev/null
+++ b/kern/gsync.c
@@ -0,0 +1,258 @@
+/* Copyright (C) 2016 Free Software Foundation, Inc.
+ Contributed by Agustina Arzille , 20
48 matches
Mail list logo
