From: Neil Jerram <neil@ossau.uklinux.net>
To: "Julian Graham" <joolean@gmail.com>
Cc: "Ludovic Courtès" <ludo@gnu.org>, guile-devel@gnu.org
Subject: Re: srfi-18 requirements
Date: Sat, 08 Mar 2008 16:34:37 +0000 [thread overview]
Message-ID: <87bq5pb2ea.fsf@ossau.uklinux.net> (raw)
In-Reply-To: <2bc5f8210803011156i3bfb976bsda2a7902654ba3a6@mail.gmail.com> (Julian Graham's message of "Sat, 1 Mar 2008 14:56:07 -0500")
"Julian Graham" <joolean@gmail.com> writes:
> Find attached the latest revision of the core changes for SRFI-18
> support. Key changes between this revision and the last are:
>
> * scm_to_timespec -> to_timespec
> * "Timeout values" for timed joins
> * The extension of make-mutex and addition of make_mutex_with_flags to
> support additional configuration options that persist for the lifetime
> of a mutex (unchecked unlocking and external unlocking)
> * fat_mutex_unlock now takes a condition variable and a timeout to
> support SRFI-18's condition-signal unlock semantics; mutex unlocking
> and condition variable waiting are reimplemented in terms of
> fat_mutex_unlock; unnecessary relocking / unlocking is no longer
> performed
> * The threads tests and scheduling documentation have been updated to
> reflect the above.
>
> Let me know what you think!
It looks great. I still have a few minor queries, but it's close
enough now that I've committed this latest patch to CVS; it'll be much
more convenient to work on the few remaining queries incrementally,
rather than with respect to threads.c as it was prior to all these
changes.
> -@deffn {Scheme Procedure} make-mutex
> +@deffn {Scheme Procedure} make-mutex . flags
> @deffnx {C Function} scm_make_mutex ()
> -Return a new standard mutex. It is initially unlocked.
> +@deffnx {C Function} scm_make_mutex_with_flags (SCM flag)
flag -> flags here?
> +static void
> +to_timespec (SCM t, scm_t_timespec *waittime)
> +{
> + if (scm_is_pair (t))
> + {
> + waittime->tv_sec = scm_to_ulong (SCM_CAR (t));
> + waittime->tv_nsec = scm_to_ulong (SCM_CDR (t)) * 1000;
> + }
> + else
> + {
> + double time = scm_to_double (t);
> + double sec = scm_c_truncate (time);
> +
> + waittime->tv_sec = (long) sec;
> + waittime->tv_nsec = (long) ((time - sec) * 1000000);
1000000 -> 1000000000 ?
> +static SCM unchecked_unlock_sym;
> +static SCM allow_external_unlock_sym;
> +static SCM recursive_sym;
Use SCM_SYMBOL here? As the init code stands, this means that the
symbols will end up being created in scm_init_thread_procs(), but I
think that will be fine, as the symbols are only useful in procedure
calls.
> +
> +SCM_DEFINE (scm_make_mutex_with_flags, "make-mutex", 0, 0, 1,
> + (SCM flags),
> "Create a new mutex. ")
> -#define FUNC_NAME s_scm_make_mutex
> +#define FUNC_NAME s_scm_make_mutex_with_flags
> {
> - return make_fat_mutex (0);
> + int unchecked_unlock = 0, external_unlock = 0, recursive = 0;
> +
> + SCM ptr = flags;
> + while (! scm_is_null (ptr))
> + {
> + SCM flag = SCM_CAR (ptr);
> + if (scm_is_eq (flag, unchecked_unlock_sym))
> + unchecked_unlock = 1;
> + else if (scm_is_eq (flag, allow_external_unlock_sym))
> + external_unlock = 1;
> + else if (scm_is_eq (flag, recursive_sym))
> + recursive = 1;
> + else
> + SCM_MISC_ERROR ("unsupported mutex option", SCM_EOL);
Perhaps we can generate a more explicit error here, indicating the
actual problem value? See other calls to scm_misc_error() where the
3rd parameter is not SCM_EOL.
> +static int
> +fat_mutex_unlock (SCM mutex, SCM cond,
> + const scm_t_timespec *waittime, int relock)
> {
> - char *msg = NULL;
> + fat_mutex *m = SCM_MUTEX_DATA (mutex);
> + fat_cond *c = NULL;
> + scm_i_thread *t = SCM_I_CURRENT_THREAD;
> + int err = 0, ret = 0;
>
> scm_i_scm_pthread_mutex_lock (&m->lock);
> if (!scm_is_eq (m->owner, scm_current_thread ()))
> {
> if (scm_is_false (m->owner))
> - msg = "mutex not locked";
> - else
> - msg = "mutex not locked by current thread";
> + {
> + if (!m->unchecked_unlock)
> + scm_misc_error (NULL, "mutex not locked", SCM_EOL);
> + }
> + else if (!m->allow_external_unlock)
> + scm_misc_error (NULL, "mutex not locked by current thread", SCM_EOL);
> + }
Need to unlock m->lock before raising the error?
> SCM_DEFINE (scm_timed_wait_condition_variable, "wait-condition-variable", 2, 1, 0,
> @@ -1393,20 +1590,11 @@
>
> if (!SCM_UNBNDP (t))
> {
> - if (scm_is_pair (t))
> - {
> - waittime.tv_sec = scm_to_ulong (SCM_CAR (t));
> - waittime.tv_nsec = scm_to_ulong (SCM_CAR (t)) * 1000;
> - }
> - else
> - {
> - waittime.tv_sec = scm_to_ulong (t);
> - waittime.tv_nsec = 0;
> - }
> + to_timespec (t, &waittime);
> waitptr = &waittime;
> }
>
> - return scm_from_bool (fat_cond_timedwait (cv, mx, waitptr));
> + return fat_cond_timedwait (cv, mx, waitptr) ? SCM_BOOL_T : SCM_BOOL_F;
Better to eliminate fat_cond_timedwait completely now, I think.
(i.e. Just rewrite the last line as a fat_mutex_unlock() call.)
Finally, please note that we will need a NEWS entry for this work.
Are you happy to write that too? (You may of course prefer to defer
this until the SRFI-18 Scheme parts are committed too - that's
absolutely fine.)
Regards,
Neil
next prev parent reply other threads:[~2008-03-08 16:34 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-11 1:54 srfi-18 requirements Julian Graham
2007-10-12 8:42 ` Ludovic Courtès
2007-10-12 15:31 ` Julian Graham
2007-10-15 22:26 ` Julian Graham
2007-10-15 22:35 ` Stephen Compall
2007-10-15 22:47 ` Julian Graham
2007-10-29 14:37 ` Julian Graham
2007-11-26 18:11 ` Julian Graham
2007-11-27 9:14 ` Ludovic Courtès
2007-11-28 18:23 ` Ludovic Courtès
2007-11-28 18:55 ` Julian Graham
2007-12-01 5:08 ` Julian Graham
2007-12-01 10:21 ` Ludovic Courtès
2007-12-02 3:59 ` Julian Graham
2007-12-04 22:20 ` Neil Jerram
2007-12-04 22:29 ` Neil Jerram
2007-12-11 4:20 ` Julian Graham
2007-12-18 4:30 ` Julian Graham
2007-12-28 18:46 ` Ludovic Courtès
2007-12-28 19:08 ` Julian Graham
2007-12-28 22:35 ` Neil Jerram
2007-12-30 11:04 ` Neil Jerram
2007-12-30 20:38 ` Julian Graham
2008-01-01 19:09 ` Neil Jerram
2008-01-04 5:01 ` Julian Graham
2008-01-05 0:30 ` Neil Jerram
2008-01-06 21:41 ` Julian Graham
2008-01-08 23:11 ` Neil Jerram
2008-01-11 2:39 ` Julian Graham
2008-01-17 1:48 ` Neil Jerram
2008-01-19 20:10 ` Julian Graham
2008-01-23 22:46 ` Neil Jerram
2008-01-23 23:23 ` Julian Graham
2008-01-25 1:07 ` Neil Jerram
2008-01-25 1:38 ` Julian Graham
2008-01-28 2:06 ` Julian Graham
2008-02-03 0:30 ` Neil Jerram
2008-02-05 6:27 ` Julian Graham
2008-02-07 1:23 ` Neil Jerram
2008-02-07 3:06 ` Julian Graham
2008-02-07 23:26 ` Neil Jerram
2008-02-07 23:33 ` Julian Graham
2008-02-07 23:38 ` Neil Jerram
2008-02-08 0:04 ` Julian Graham
2008-02-11 5:14 ` Julian Graham
2008-02-19 22:48 ` Neil Jerram
2008-02-20 2:10 ` Julian Graham
2008-02-22 0:33 ` Neil Jerram
2008-02-22 4:14 ` Julian Graham
2008-02-24 9:41 ` Neil Jerram
2008-02-24 18:17 ` Julian Graham
2008-02-24 23:29 ` Neil Jerram
2008-03-01 19:56 ` Julian Graham
2008-03-08 16:34 ` Neil Jerram [this message]
2008-03-11 4:02 ` Julian Graham
2008-03-22 18:55 ` Julian Graham
2008-03-23 23:57 ` Neil Jerram
2008-03-24 22:03 ` Neil Jerram
2008-03-26 15:55 ` Julian Graham
2008-04-03 0:18 ` Neil Jerram
2008-04-03 19:07 ` Julian Graham
2008-04-09 21:29 ` Neil Jerram
2008-04-14 0:43 ` Julian Graham
2008-05-14 1:23 ` Julian Graham
2008-05-14 21:13 ` Neil Jerram
2008-05-14 23:11 ` Neil Jerram
2008-05-15 5:05 ` Julian Graham
2008-05-24 11:42 ` Neil Jerram
2008-05-24 13:55 ` Neil Jerram
2008-05-25 2:07 ` Julian Graham
2008-05-31 21:41 ` Ludovic Courtès
2008-06-02 4:48 ` Julian Graham
2008-06-21 5:03 ` Julian Graham
2008-06-30 17:51 ` Ludovic Courtès
2008-01-08 23:41 ` Neil Jerram
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bq5pb2ea.fsf@ossau.uklinux.net \
--to=neil@ossau.uklinux.net \
--cc=guile-devel@gnu.org \
--cc=joolean@gmail.com \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).