Re: How could HP help Debian
On Tue, Sep 16, 2003 at 12:33:45AM -0400, Grzegorz B. Prokopski wrote:
> Well, okay, I forgot about the idea of doing it in userspace if you
> say so, but would you be able to point me to some discussion that
> led to this conclusion? I looked at debian-hppa archives in previous
> months but found nothing related (judging from topics).
As Randolph noted most of the discussion was "off-line" at OLS.
> However I talked with Etienne today (main SableVM author) and it should
> be possible to make SableVM working using pthread locks with minimal
> effort on the side of SableVM (and probably small performance loss).
And when you take a signal during the atomic operation and the signal
handler wants to run another atomic operation on the same area of
memory? Deadlock. It gets messy.
> So I'd like to know whether HPPA has sane implementation of pthread
> locks? I saw those two messages:
> http://lists.debian.org/debian-hppa/2003/debian-hppa-200303/msg00009.html
We have a very sane an simple pthread implementation.
> http://lists.arm.linux.org.uk/pipermail/linux-arm/2002-June/003710.html
> First one updates pthread implementation for HPPA (which is promising
> fact) but second, related to arm, says about performance problems of
> pthread locks which could be solved by impelmenting cmp&swap which then
> could be used by pthreads.
The problem there is ARM defined HAS_CAS but didn't use the (wrong
headers were included) atomicity.h version and thus fell back to a
spinlock with testandset. This was horrible for performance. We don't
have CAS in hardware, so we don't define HAS_CAS instead we are always
forced to loop on ldcw. It's just the way it's done on HPPA. The better
scenario is to write lock-free code using lock-free algorithms.
> Well - as I said before - my main objective is to get SableVM working
> for HPPA (which is not that bad goal in your eyes, I hope ;-) so if
> I could go with pthread implementation for now - then OK.
Use pthreads. Atomicity not guaranteed. And deadlocks might happen if
the signal handler does more complex things.
> In such case the LIBFFI implementation would be the key for it.
> I am not an expert here, but from SableVM sources I may say that
> it uses a lot of ffi_type_*, once ffi_prep_cif and some ffi_call.
> If you think that there are any chances to make SableVM working with
> your libffi for HPPA implementation - I would certainely would like to
> get access to this code.
:)
c.
Reply to: