guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some introductory docs about C level threading


From: Marius Vollmer
Subject: Re: Some introductory docs about C level threading
Date: Thu, 10 Feb 2005 12:36:35 +0100
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux)

Kevin Ryde <address@hidden> writes:

> Marius Vollmer <address@hidden> writes:
>>
>> Why?
>
> I'm thinking that you build a list structure or whatever, then plonk
> it somewhere other threads can access it.  When another thread can see
> that final store, you'd like it to see all the stores that preceded it
> which built the structure.

Yes, that is a very good example.  Hmm, I would say that it is OK to
_not_ guarantee that the second thread sees all the stores of the
first thread when it accesses the structure, _except_ that the
structure it guaranteed to be a valid Scheme object.

Of course, you want the second thread to see all the stores.  For
that, you need to do something special in you Scheme program, such as
protecting the global variable with a mutex, although the store into
it is expected to be atomic and thus wouldn't normally need
protection.

Hmm.

> Maybe that's too optimistic, but at the scheme level I think it's what
> you'd like to end up with, ie. data usable from any thread without
> special transfers or syncs.

Yes, but multi-threaded programming does not seem to work this way.  I
would agree that it sucks, and that people should rather make
programming easier (by guaranteeing memory consistency between threads
of a single process, say) instead of going for artificial benchmark
numbers.  Memory coherency should probably be an option of mmap and
only the truly brave would turn it off...


We could try to offer a nicer memory model to Scheme programs, but we
would have to do it by disallowing true concurrency, I think.  We had
this option a while ago, with the coop-pthreads.  It was a simple
implementation of cooperating threads on top of pthreads.  Only one
thread would be in guile mode at any one time.  As I said elsewhere, I
like this idea very much, but right now, I am trying to go for full
concurrency.  The problem will likely be that in the end, Guile will
work good enough in practice, but there will always be the nagging
doubt whether it really is completely correct.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]