Re: scm_i_fraction_reduce thread safety

From: Mikael Djurfeldt <mdj@mit.edu>
Cc: Marius Vollmer <m.vollmer@ping.de>,
	guile-devel@gnu.org, djurfeldt@nada.kth.se,
	Carl Witty <cwitty@newtonlabs.com>,
	Rob Browning <rlb@defaultvalue.org>
Subject: Re: scm_i_fraction_reduce thread safety
Date: Fri, 30 Jan 2004 09:45:28 -0500	[thread overview]
Message-ID: <xy77jz97awn.fsf@chunk.mit.edu> (raw)
In-Reply-To: <87ekti7dka.fsf@zagadka.ping.de> (Marius Vollmer's message of "Thu, 29 Jan 2004 20:35:49 +0100")

Marius Vollmer <mvo@zagadka.de> writes:

> Rob Browning <rlb@defaultvalue.org> writes:
>
>> In any case, do we have a "current plan" with respect to threading,

There is a document threads/thread-interface.text in workbook which is
not a plan, but which brings up things which should be considered when
making decisions on the organization of threading in Guile.

> I don't have one ready, but I do very much want to have one before
> 1.8.  I need to decide for myself whether I would want to go for full
> concurrency or for restricting us to a one-thread-at-a-time model.
>
> Full concurrency is not a nice-model to program for,
> one-thread-at-a-time wont be able to take advantage of multiple
> processors.

My view is that the current organization of threading in HEAD has a
lot of promise.  It does give full concurrency, at the same time as it
is usually quite easy to program for.

For the application writer or Guile user who doesn't want to concern
himself with threading there is nothing special to think about.

For those who do write threaded programs, there *could* be a
distinction between thread-safe and thread unsafe resources.  They
would need to use mutecis etc explicitly in the latter case.

However, usually, there is not much to think about even at the C
level.  Since the garbage collector, in the current scheme, only can
be invoked at special well-defined places in the code, there is
nowadays not even a need for the SCM_DEFER/ALLOW_INTS critical
sections.  Many of those in the current code can simply be removed.

I know what I'm talking about here since I have written threaded
applications using HEAD.  Two have been using gtk-1.2, with an event
handler thread, and multiple threads accessing the graphics.

I think the highest demands is put on the Guile developers, because
there are probably quite a few parts of Guile which we probably would
like to have the ambition to make thread-safe (although we wouldn't
need to in all cases).  But even in this case, we shouldn't exaggerate
the problem.  Basically, the main thing to look out for is when we
have code which changes the state of something which is available for
other threads.  That doesn't happen too often.

There could of course turn up tricky problems with regard to threaded
semantics in areas such as signals and exceptions.

On the other hand, I think the benefits of allowing full pthreads
support are great.  Among other roles, Guile is an application
extension language.  I think it is up to the application writer to
decide which thread library he wants to use, so I'd like to see Guile
being able to support various thread libraries, the choice being made
at Guile initialization time.  (These things are discussed in the
thread-interface.text document mentioned above.)

If the application writer have chosen pthreads, I wouldn't say the
downside of removing full concurrency is only with regards to
multi-CPU support.  What is almost more important is the constraints
that will cause on the design of the application.  The application
writer will then be limited with respect to the designs he can choose
between.  For example, if we don't support full concurrency, the
application writer can't easily write Scheme extensions (Scheme
primitives) which run concurrently.  (This statement may or may not be
true depending on the exact form of the restriction you are thinking
about.)

Also, supporting pthreads without full concurrency on the Scheme side
will likely introduce more overhead than we have now in HEAD because
of all arbitration using mutecis and condition variables that would
entail.

Finally, while multi-CPU support may look exotic now, it's not
unlikely that it will become a common thing in within just a few years
once the hardware makers eventually run into the long-predicted
barriers for making things faster along the current route.

I think it would be sad to build ourselves into a corner in this
respect...

M

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel