Re: Resizing hash tables in Guile

[Mikael Djurfeldt <djurfeldt@nada.kth.se>]

Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:

> Roland Orre <orre@nada.kth.se> writes:
>
>> > I made the hash tables thread-safe (locking/unlocking a mutex at hash
>> > table access and rehashing).  Is that good?  An alternativ is to
>> > require of the programmer to make sure the hash tables aren't accessed
>> > in parallel.
>> 
>> In our case I think we will most likely set up the different processes
>> to use different hash tables but we have still not parallellized our
>> applications. Could/should the mutex protection maybe be optional?
>
> Since users must consciously ask for resizable hash tables, we can
> require them to do the locking themselves.  Should we?  I would say
> yes, since people need to be aware of thread issues anyway, and maybe
> they have a better scheme for ensuring thread safe access to a hash
> table.

I agree.  When implementing the current thread safety I've encountered
a cluster of very interesting problems.  I'll write up a small text
about this, put in the workbook and post on the list.  I'd say I can
do this within a few weeks.  For example, I've discovered that the
with-mutex construct we provide in threads.scm is of dubious utility.
It also seems hard to second-guess the "users" needs when trying to
provide high-level thread-safety constructs in general.

I'll remove the thread protection code from hashtab.c.

> Removing the locking from the core code should improve performance,
> right?

Yes, at least marginally.

> However, the hash tables should be somewhat thread safe: they might
> not work as advertised when multiple threads access them, but the
> application might not crash.  That is, adding an element from one
> thread while another thread is doing the same thing might make one of
> the elements disappear, but it must leave the hash table in a valid
> state.
>
> Do the non-resizing hash tables behgave that way, incidentally?

I'd say yes.

> (Ahh, I just love cooperative threading.  These things are so much
> easier and efficient when there is only one running thread with
> defined switch points... :-)

I think the current restriction on signals only causing exceptions at
well defined points takes us a good way towards that.  I doubt that
there are still many points in Guile which need to be modified to get
the thread safety to where we want it.

M


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