Non-pre-emptive POSIX threads for 68k Amiga ported

[whoosh777]

Announcing a straight port to m68k Amiga of Ralf S Engelschall's implementation of POSIX threading. This is a non pre-emptive implementation, being non pre-emptive makes it a very clean port.

It took one day to port in comparison to an attempt to port a pre-emptive implementation which I gave up on after over a week.

To see threading in action on a 68k Amiga with ixemul.library download and run an example program: "the 5 philosophers": http://www.whoosh777.pwp.blueyonder.co.uk/test_philo

I have no idea if it will run on PPC or Amithlon; e-mail me if you try out test_philo.

For the port itself visit
http://www.whoosh777.pwp.blueyonder.co.uk/pthreads.html

This port is gcc linker libraries: libpthread.a and libpth.a so its not a user-level thing. Nor is it an OS level thing, just a gcc linker thing.

However, programs linked with it such as the above example are user level.

I did this port because I recently ported rpm with the database facility disconnected as that requires libpthread.a. So I could now do a full port of rpm4.0 (I hope).

[jahc]

So does this mean it will be slightly easier to port Linux software now?

[whoosh777]

@jahc said:

==========================

So does this mean it will be slightly easier to port Linux software now?

==========================

yes, and having libpthread.a may make some otherwise impossible
ports possible.

an example being rpm which is a Red Hat Linux program,

rpm from version 4.0 upwards uses db 3.0 upwards which in
turn requires either libpthread or libthread.

rpm3 I think doesnt require libpthread, but it also cannot extract from recent
#?.rpm files as I discovered!

So if you want to be current you are forced to port rpm4.#?,

I ported rpm4.0 last December and got around lack of libpthread
by disconnecting the database facility. (analogous to surgical
removal of snake bite venom!)

Anyway now it should be possible to do a full port of rpm4.0
and possibly even rpm4.2 (rpm4.2 contains a lot of irrelevant-to-the-amiga
stuff which will also need surgical removal)

Now there was also a choice between libthread and libpthread,
after looking into this I found that the recommended path
is libpthread.

the p in libpthread standing for POSIX, POSIX being a way to write
 programs which will port across the board.
ie if you obey the rules of POSIX when coding then your program
will port to all platforms: Mac, Linux, Unix, Windows, Amiga,

classic Amiga is largely POSIX compliant,

So if a POSIX program threads then probably this will be via libpthread,

Anyway, having libpthread.a allows us to delete one of the
obstacles to the classic Amiga catching up.

[hnl_dk]

Sorry to tell you, but it is part of GeekGadgets (Alpha)
ftp://ftp.geekgadgets.org/pub/geekgadgets/amiga/m68k/alpha/pth/

even 1.4.1 :-D

Have you tried version 2.0.0+?

http://www.ossp.org/pkg/lib/pth/

There are also the development snapshots: ftp://ftp.ossp.org/pkg/lib/pth/

[hnl_dk]

Hope you get your RPM port to work (including db) :-D

[whoosh777]

As you are cutting and pasting your posts, so will I!
(I have added some extra stuff to the original reply),


@hnl_dk said:

=========================================================

Sorry to tell you, but it is part of GeekGadgets (Alpha)
ftp://ftp.geekgadgets.org/pub/geekgadgets/amiga/m68k/alpha/pth/

even 1.4.1

======================================================


ok, but why is it in the alpha directory?


In fact why are they all alpha?

and 1.4.1 has been alpha since 2002,

Whats the point of porting a new version when the previous
version never left alpha?


Thats like failing the exams and moving on nonetheless to the
next grade!


rpm4.0 is in the Geek alpha directory and it totally malfunctions,
thats why I did my own port. Its also why I now ignore the alpha
directory and so didnt see the Geek alpha pth.


The configure for this port is *very* tricky, has maybe 10 different
bugs which trip up all over the place on AmigaOS,
there is also a bug in a Geekgadgets include file which will sink a port.
Thats why the port took 1 day instead of say 1/2 hour which libbz2.a took.


If the port passes all the example test programs which my port
has then it should never have entered the alpha directory.


You can verify for yourself that my port is not an alpha by
trying 7 of the test programs in
http://www.whoosh777.pwp.blueyonder.co.uk/threaded_68kprograms.lha,


:test_std is the important test.


I can upload the remaining 2 test programs also: test_select
which doesnt do very much and test_sfio which is irrelevant as
I havent compiled in sfio.


Now OTOH with the pre-emptive version of libpthread.a which I attempted
*all* the supplied test programs failed, so that attempted port would be in
the alpha directory.


==============================================================

Have you tried version 2.0.0+?

http://www.ossp.org/pkg/lib/pth/

There are also the development snapshots: ftp://ftp.ossp.org/pkg/lib/pth/

====================================================


Didnt know it existed, I visited the only link I found and 1.4.0
was the latest version. When time permits I may attempt this,
(I have had a look now and that appears to be the most current version,
I wish you had told me this earlier ),

for the moment I think the current port is probably quite adequate.
Keeping up with version numbers is a treadmill. IMO one should only
keep up with version numbers out of necessity eg rpm4.#? needed to
be done because rpm3 and earlier will not extract from current
#?.rpm files.


All I know is that my port is fully functioning, all test example
programs function, so it would never enter an alpha directory,


my attempt at pre-emptive libpthread.a OTOH would be in an alpha directory
and also would be quite useless. I will make one last attempt to
port it tonight, and then I am moving on to other projects.
(at a later point I may return to pth-2.0.0 and rpm4.#?)


BTW how come no-one pointed me to pth when I ported rpm4.0 and
said that I need libpthread.a to do a full port?


Re: db, when I have some spare time I may try to do a full port of rpm4.0,
however IMO the db facility is an irrelevant gimmick on AmigaOS.
On Linux you probably need the db facility because Linux is so
humungously bloated that its a full time job keeping it maintained.


BTW I should point out another use for the port is if someone
wants to write their own threaded programs. Using libpthread.a would
be a good idea as the threading mechanism would be fully portable.
Probably its wise to learn to write threading on cross-platform
threads such as libpthread as the mechanism will have been vetted
by a lot of people.


So 68k Amiga not having OS threads may be a good thing in that
it will force programmers to write portable threaded code.


Moving from 1 thread mechanism to another can be quite tricky
as apparently they implemented libpthread.a for Windows via
Windows own OS threads. And doing this was a big challenge.
Trying to implement libpthread.a by any means is quite tricky as
the specification is so impenetrable.


whoosh

[hnl_dk]

Hi' whoosh ...

I first made the post on AW.net ... but as I saw that you already had made a reply here, I thought I had to be sure, and also make the post here ;-)

I think it is great that you have made the port :-D So thanks :-D

Right now I'm not able to try it... but I will when I get an AmigaOne (with UAE ;-))

Sorry about not telling you about 2.0.0 ;-)
But I have told some others ;-) I want someone to make a port for AmigaOS4 ;-)
Might do it myself, when I get the beast (the money for it) ... and the time :-(

About the development snapshot, that one was "hard" to find, as the link on the page does link to the wrong date (it also did it in oktober)

Off Topic:
Are you going PPC sometime in the near future? (not asking specific OS)

[jeffimix]

Why do I keep thinking 'Amizilla' when I hear about this.

What's the word, Firebird!

[whoosh777]

@hnl_dk said:

=======================================


Hi' whoosh ...

I first made the post on AW.net ... but as I saw that you already
had made a reply here, I thought I had to be sure, and also make
the post here

=======================================


ok, I understand the thought process!


=======================================


>I think it is great that you have made the port So thanks


=====================================


After doing pth I believe now that the classic Amiga
can catch up indefinitely with the other platforms
although achieving this can sometimes be painful.
Some catch up probably may require a graphics card.
Coldfire would achieve speed catch up, if Motorola
could be bothered to put money into it I dont see
why 68k couldnt go the same distance as x86.


Maybe if they forget about the heat factor and do
a Hotfire then full catch up with x86 could happen?


(or even a hot PPC!)


I think it is generally said that one major
reason 68k Amiga cannot fully catch up is because
of threading. Well you can download those example
programs to see threading in action.


I made the announce because I had been led to believe
that threading on 68k was near impossible. I never
dreamed it could be done in 1 day!


So now that I had ported threading to my system I thought
I should make it known that 68k can thread.


I was completely unaware of the alpha subdirectory you
pointed out. Even had I looked in the alpha directory
I would never have looked in pth because "pth" doesn't sound
like "thread".


There are so many zillions of things on the internet that
if a name is not descriptive enough you can easily gloss over it.


its the problem of information overload,


Note that no-one at all said anything at all about
libpthread.a when I did the rpm4.0 with databases
disconnected


=========================================


>Right now I'm not able to try it... but I will when I get an AmigaOne (with UAE)


>Sorry about not telling you about 2.0.0

======================================


I think I will port 2.0.0, if only to get out of the alpha fiasco!


1.4.0 was not too severe, and the c code is so well written
(I only had to alter 1 line of the c code),
so 2.0.0 is probably worth an attempt at least.


At the moment I am in danger of trying to work on too
many different things, so no promises on when I will attempt
it. I need also to set aside some time for Unix related
learning curve for making fuller use of Geekgadgets on the Amiga.
To avoid vapour I try only to publicly mention things after they
are fully functioning.


So its going to be a while before the one port integrates into
other ports. I may wait till I am on a faster machine before
attempting more ambitious ports. On my 68030 the more
severe ports can take an entire day just to configure and an entire
day to compile. A G3 being 100 times as fast, means that
1 day on a 68030 becomes a mere 24 x 60 /100 = 14 minutes on a G3,
so development will become much faster. eg you could locate the
problem points much faster,


:At the moment I am reading Charles ####ens book David Copperfield
while the compiler is busy, keeping an eye out for crashes and
malfunctions from the computer and keeping an ear out for
disk inactivity (usually means problems).
In David Copperfield there are no computers, no cars even, great!
people move around on a cart and all transport is horse drawn!
There are an endless number of fantastic characters and events
in the story,
I am reading it at a leisurely pace as this story cannot be rushed,
its as funny as Victorian Dad or Spoilt Bastard (read my lips!)
 used to be in Viz comic, (last century Viz used to be really great,
but now it has lost its direction so I no longer buy it)


===================================================


>But I have told some others I want someone to make a port for AmigaOS4
>Might do it myself, when I get the beast (the money for it) ... and the time


===================================================


once Hyperion make available the developer tools I can certainly
attempt either this or other work. For UAE I presume only 68k programs
 are relevant?


===========================================

>About the development snapshot, that one was "hard" to find, as the
>link on the page does link to the wrong date (it also did it in oktober)

===================================


I know good code when I see it and pth is first division coding,
and the fact that pthread is implemented via pth shows that the
author is fully aware of what the other guys are doing,


in other ports I have waded through reams of horrible code,
pth is actually fun to read, I think that being non-pre-emptive
actually makes the "architecture" much more elegant.


coding is like prose and everyone has their own style,
and like prose some code is a joy to read and other
code isnt.


threads seem to be very well hidden. Any developer stuff that is
very useful is very well hidden! You have to do a lot of
lateral thinking to locate the useful things.


Feeding eg pthread and tar.gz into Google or Yahoo will never lead you to
pth.


======================================


>Off Topic:
>Are you going PPC sometime in the near future? (not asking specific OS)


=====================================


I am certainly planning to, I think I have the necessary funds
ready: they are currently earning a good rate of interest in an
instant access account!


If I go PPC I think I will still create 68k programs as
they will run on all systems (68k, Morphos, OS4, Amithlon).
I will also when writing my own programs try and keep within
the OS3.1 API: this would then anticipate any AROS progress.
so I could port my own programs to any platforms AROS reaches.


Porting Unix progs to 68k also means they can then reach
anywhere AROS reaches. OS3.1 68020 no fpu is kind of a porting portal or hub,


If I go beyond the classic 3.1 API I will do this in a careful way
to anticipate porting. In theory a lot of www.aminet.net could port
to any place that AROS reaches.


Till this day all progs I have written lie within the OS3.0 API,
the reason being that I have a total developer environment for
OS3.0: RKMs, autodocs, SASC6.50 with its extensive docs.
Also such programs will run on all A1200s and A4000s ever manufactured.