From: Richard Todd <richardt@vzavenue.net>
Cc: Bill Schottstaedt <bil@ccrma.stanford.edu>,
guile-devel@gnu.org, Carl Witty <cwitty@newtonlabs.com>,
Marius Vollmer <mvo@zagadka.de>
Subject: Re: scm_i_fraction_reduce thread safety
Date: Sun, 11 Jan 2004 23:22:29 -0600 [thread overview]
Message-ID: <40022F15.30903@vzavenue.net> (raw)
In-Reply-To: <87zncuat0g.fsf@zip.com.au>
Kevin Ryde wrote:
> Marius Vollmer <mvo@zagadka.de> writes:
>
>>User code should only use scm_numerator and scm_denominator to access
>>parts of the fraction object and those functions will first reduce the
>>fraction (in a thread safe way). Wouldn't that be enough?
>
>
> Yep, though it seems a shame the accessors have to be slowed down just
> so printing and equality can write back.
I may not fully understand this, but after reading through the messages
on the list, and having been awake for 36 hours, I can't help but think
at least two things:
1) If you are worried about thread safety, the most fool-proof C
interface probably does not allow separate access to numerator and
denominator, since they need to be read in one atomic operation to
ensure consistent results in the face of other mutating code.
2) Aren't (numerator frac) and (denominator frac) themselves other
examples of would-be readers that might have to 'write back' in this
setup? According to r5rs they return the reduced value.
For the speed issue in general, doesn't it come down to whether the
extra gcd()s of eager reduction would be cheaper than the mutex_lock()s
of lazy reduction? If I'm thinking straight, the mutex only seems
necessary if SCM_FRACTION_REDUCED(n) == #f, so as long as you don't
mutate/reduce/mutate/reduce in a tight loop, there may not be much
mutexing at all. Seems like it could be tried both ways.
Richard
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2004-01-12 5:22 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-11 11:43 scm_i_fraction_reduce thread safety Bill Schottstaedt
2003-12-11 19:19 ` Carl Witty
2003-12-12 12:11 ` Bill Schottstaedt
2003-12-12 15:04 ` Paul Jarc
2003-12-12 23:23 ` Kevin Ryde
2004-01-10 22:38 ` Marius Vollmer
2004-01-10 23:29 ` Kevin Ryde
2004-01-11 1:31 ` Marius Vollmer
2004-01-12 0:51 ` Kevin Ryde
2004-01-12 5:22 ` Richard Todd [this message]
2004-01-14 21:09 ` Kevin Ryde
2004-01-21 0:03 ` Marius Vollmer
2004-01-21 0:00 ` Marius Vollmer
2004-01-21 3:11 ` Carl Witty
2004-01-21 21:06 ` Marius Vollmer
2004-01-27 22:15 ` Dirk Herrmann
2004-01-27 23:24 ` Rob Browning
2004-01-29 19:35 ` Marius Vollmer
2004-01-29 20:32 ` Rob Browning
2004-01-30 14:45 ` Mikael Djurfeldt
2004-02-01 18:49 ` Andy Wingo
-- strict thread matches above, loose matches on Subject: below --
2003-12-09 20:39 Kevin Ryde
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=40022F15.30903@vzavenue.net \
--to=richardt@vzavenue.net \
--cc=bil@ccrma.stanford.edu \
--cc=cwitty@newtonlabs.com \
--cc=guile-devel@gnu.org \
--cc=mvo@zagadka.de \
/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).