Re: How could HP help Debian
- To: "Grzegorz B. Prokopski" <email@example.com>
- Cc: firstname.lastname@example.org, Randolph Chung <email@example.com>
- Subject: Re: How could HP help Debian
- From: Carlos O'Donell <firstname.lastname@example.org>
- Date: Tue, 16 Sep 2003 16:48:46 -0400
- Message-id: <20030916204845.GJ30481@systemhalted>
- In-reply-to: <1063686823.963.76.camel@greg>
- References: <Pine.LNX.email@example.com> <1063593016.882.46.camel@greg> <20030915024546.GP21596@parcelfarce.linux.theplanet.co.uk> <20030915044720.GD3998@systemhalted> <1063602372.881.111.camel@greg> <20030915135408.GA9651@systemhalted> <1063636949.963.8.camel@greg> <20030915163110.GC9651@systemhalted> <1063686823.963.76.camel@greg>
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:
We have a very sane an simple pthread implementation.
> 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.