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: Tue, 19 Feb 2008 22:48:47 +0000 [thread overview]
Message-ID: <87pruso94g.fsf@ossau.uklinux.net> (raw)
In-Reply-To: 2bc5f8210802102114m4eab895dr3114b7ea74156b38@mail.gmail.com
"Julian Graham" <joolean@gmail.com> writes:
> Okay, find attached a patch against HEAD containing the aforementioned
> changes to the core for supporting SRFI-18. I'm still looping my test
> code, but I thought I should get something out to you guys this
> evening. In addition to the code changes, the patch includes relevant
> Changelog, doc, and threads.test updates. Let me know what you think.
Looking good! Many thanks for your continuing work on this, and sorry
for my delay (once again!) in reviewing. I have a few comments, as
follows.
> @c begin (texi-doc-string "guile" "join-thread")
> -@deffn {Scheme Procedure} join-thread thread
> +@deffn {Scheme Procedure} join-thread thread [timeout]
> @deffnx {C Function} scm_join_thread (thread)
> +@deffnx {C Function} scm_join_thread_timed (thread, timeout)
Didn't we agree to add a timeout-val parameter here?
> +static scm_t_timespec
> +scm_to_timespec (SCM t)
For static functions it's nice to omit the scm_ prefix, because they
don't need it, and it makes it clearer to the casual reader that
they're not part of the API.
Also, can the signature be void to_timespec (SCM t, scm_t_timespec *),
to avoid relying on support for struct return?
> -SCM_DEFINE (scm_join_thread, "join-thread", 1, 0, 0,
> - (SCM thread),
> +SCM scm_join_thread (SCM thread)
> +{
> + return scm_join_thread_timed (thread, SCM_BOOL_F);
You should use SCM_UNDEFINED to indicate an absent parameter, rather
than SCM_BOOL_F.
> +}
> +#undef FUNC_NAME
Last #undef line is extraneous.
> +
> +SCM_DEFINE (scm_join_thread_timed, "join-thread", 1, 1, 0,
> + (SCM thread, SCM timeout),
What about the timeout_val parameter ...
> "Suspend execution of the calling thread until the target @var{thread} "
> "terminates, unless the target @var{thread} has already terminated. ")
> -#define FUNC_NAME s_scm_join_thread
> +#define FUNC_NAME s_scm_join_thread_timed
> {
> + int timed_out = 0;
> scm_i_thread *t;
> - SCM res;
> + scm_t_timespec ctimeout, *timeout_ptr = NULL;
> + SCM res = SCM_BOOL_F;
>
> SCM_VALIDATE_THREAD (1, thread);
> if (scm_is_eq (scm_current_thread (), thread))
> @@ -1005,11 +1068,23 @@
> t = SCM_I_THREAD_DATA (thread);
> scm_i_scm_pthread_mutex_lock (&t->admin_mutex);
>
> + if (! SCM_UNBNDP (timeout))
> + {
> + ctimeout = scm_to_timespec (timeout);
> + timeout_ptr = &ctimeout;
> + }
> +
> if (!t->exited)
> {
> while (1)
> {
> - block_self (t->join_queue, thread, &t->admin_mutex, NULL);
> + int err = block_self (t->join_queue, thread, &t->admin_mutex,
> + timeout_ptr);
> + if (err == ETIMEDOUT)
> + {
> + timed_out = 1;
... which I would expect to be assigned to res here.
> + break;
> + }
> if (t->exited)
Do res = t->result here, rather than below, to make clear that it goes
with the t->exited case?
> +static SCM
> +fat_mutex_lock (SCM mutex, scm_t_timespec *timeout, int *ret)
> {
> fat_mutex *m = SCM_MUTEX_DATA (mutex);
> +
> SCM thread = scm_current_thread ();
> - char *msg = NULL;
> + scm_i_thread *t = SCM_I_THREAD_DATA (thread);
> +
> + SCM err = SCM_BOOL_F;
> +
> + struct timeval current_time;
>
> scm_i_scm_pthread_mutex_lock (&m->lock);
> if (scm_is_false (m->owner))
> - m->owner = thread;
> + {
> + m->owner = thread;
> + scm_i_pthread_mutex_lock (&t->admin_mutex);
> + if (scm_is_null (t->mutexes))
> + t->mutexes = scm_list_1 (mutex);
> + else
> + t->mutexes = scm_cons (mutex, t->mutexes);
Just "t->mutexes = scm_cons (mutex, t->mutexes);" is sufficient for
both cases.
> + scm_i_pthread_mutex_unlock (&t->admin_mutex);
> + *ret = 1;
> + }
> else if (scm_is_eq (m->owner, thread))
> {
> if (m->level >= 0)
> m->level++;
> else
> - msg = "mutex already locked by current thread";
> + err = scm_cons (scm_misc_error_key,
> + scm_from_locale_string ("mutex already locked by "
> + "current thread"));
> + *ret = 0;
> }
> else
> {
> + int first_iteration = 1;
> while (1)
> {
> - block_self (m->waiting, mutex, &m->lock, NULL);
> - if (scm_is_eq (m->owner, thread))
> - break;
> - scm_i_pthread_mutex_unlock (&m->lock);
> - SCM_TICK;
> - scm_i_scm_pthread_mutex_lock (&m->lock);
> + if (scm_is_eq (m->owner, thread) || scm_c_thread_exited_p (m->owner))
> + {
> + scm_i_pthread_mutex_lock (&t->admin_mutex);
> + if (scm_is_null (t->mutexes))
> + t->mutexes = scm_list_1 (mutex);
> + else
> + t->mutexes = scm_cons (mutex, t->mutexes);
Same again here.
> + else if (!first_iteration)
> + {
> + if (timeout != NULL)
> + {
> + gettimeofday (¤t_time, NULL);
> + if (current_time.tv_sec > timeout->tv_sec ||
> + (current_time.tv_sec == timeout->tv_sec &&
> + current_time.tv_usec * 1000 > timeout->tv_nsec))
> + {
> + *ret = 0;
> + break;
> + }
Is timeout an absolute time, or relative to when join-thread was
called? Before getting to this code, I thought it was relative - but
then I don't see how the code above can be correct, because it is
comparing against the absolute gettimeofday() ...?
> -SCM_DEFINE (scm_lock_mutex, "lock-mutex", 1, 0, 0,
> - (SCM mx),
> +SCM scm_lock_mutex (SCM mx)
> +{
> + return scm_lock_mutex_timed (mx, SCM_BOOL_F);
Should be SCM_UNDEFINED.
> -static char *
> -fat_mutex_unlock (fat_mutex *m)
> +static void
> +fat_mutex_unlock (SCM mx)
> {
> - char *msg = NULL;
> -
> + fat_mutex *m = SCM_MUTEX_DATA (mx);
> scm_i_scm_pthread_mutex_lock (&m->lock);
> - if (!scm_is_eq (m->owner, scm_current_thread ()))
> + if (m->level > 0)
> + m->level--;
> + else
It looks like there is a significant change to the semantics here: any
thread can unlock a mutex, not just the thread that locked it. Is
that the intention, or am I misunderstanding?
> +static int
> +fat_cond_timedwait (SCM, SCM, const scm_t_timespec *);
>
> - return msg;
> +SCM scm_unlock_mutex (SCM mx)
> +{
> + return scm_unlock_mutex_timed (mx, SCM_UNDEFINED, SCM_UNDEFINED);
> }
>
> -SCM_DEFINE (scm_unlock_mutex, "unlock-mutex", 1, 0, 0,
> - (SCM mx),
> +SCM_DEFINE (scm_unlock_mutex_timed, "unlock-mutex", 1, 2, 0,
> + (SCM mx, SCM cond, SCM timeout),
> "Unlocks @var{mutex} if the calling thread owns the lock on "
> "@var{mutex}. Calling unlock-mutex on a mutex not owned by the current "
> "thread results in undefined behaviour. Once a mutex has been unlocked, "
> @@ -1240,18 +1358,39 @@
> "lock. Every call to @code{lock-mutex} by this thread must be matched "
> "with a call to @code{unlock-mutex}. Only the last call to "
> "@code{unlock-mutex} will actually unlock the mutex. ")
> -#define FUNC_NAME s_scm_unlock_mutex
> +#define FUNC_NAME s_scm_unlock_mutex_timed
> {
> - char *msg;
> + SCM ret = SCM_BOOL_T;
> +
> SCM_VALIDATE_MUTEX (1, mx);
> -
> - msg = fat_mutex_unlock (SCM_MUTEX_DATA (mx));
> - if (msg)
> - scm_misc_error (NULL, msg, SCM_EOL);
> - return SCM_BOOL_T;
> + if (! (SCM_UNBNDP (cond)))
> + {
> + SCM_VALIDATE_CONDVAR (2, cond);
> + scm_t_timespec cwaittime, *waittime = NULL;
> +
> + if (! (SCM_UNBNDP (timeout)))
> + {
> + cwaittime = scm_to_timespec (timeout);
> + waittime = &cwaittime;
> + }
> + if (! fat_cond_timedwait (cond, mx, waittime))
> + ret = SCM_BOOL_F;
> + }
Call scm_timed_wait_condition_variable() here, instead of duplicating
the code?
Actually, that strongly says to me that we don't need the `cond' part
of this API to be implemented in C. Can we move that to the SRFI-18
Scheme code, and leave the C API as a plain unlock-mutex operation?
Regards,
Neil
next prev parent reply other threads:[~2008-02-19 22:48 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 [this message]
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
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=87pruso94g.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).