Threads on SCO OpenServer 3.2 5.0.5
Christian
I can't find any support of threads under SCO 5.0.5. Aren't they available
on this sytem ?
Christian
Brian K. White
"Christian" <cgreg...@yahoo.com> wrote in message
news:3c8dc9ff$0$24014$4d4e...@read.news.fr.uu.net...
No kernel threads.
Someone more authoritative will have to, and surely will, comment on this,
but from what I understand there cannot be any, at least not in practical
terms. It is simply sysv r4 and above territory (aka: unixware &
open-unix), while OpenServer/OpenDesktop/SCO-Unix are all sysv r3. hence
the full actual name of "SCO 5.0.5" which is really (assuming you have
5.0.5 with tcp/ip):
"SCO Open Server Enterprise r3.2v5.0.5"
The key part here being "r3.2"
There are a few different user-space implementations in the form of
threads libraries.
ftp://ftp2.caldera.com/pub/skunkware/osr5
lipraries/pthreads # seems to be the most used
libraries/pth # seems to be more recent
also I think one or the other or something else entirely may be included
within
libraries/glib
and/or
libraries/Glib
They have been used with some success to build various of the other things
you see under skunkware/osr5 so they can be used to port existing code,
but I don't know what the real world performance benefits are to using
them in the case of writing new code for Open Server and deciding you want
to make the app threaded.
I know they basically spawn whole new full processes, which might mean
that they would automatically take advantage of multiple CPU's if you had
more than one cpu and the sco SMP software and license installed.
Can anyone comment on that?
--
Brian K. White -- br...@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
Christian
news:%Lnj8.56483$hO6.4...@bin4.nnrp.aus1.giganews.com...
Thanks for the reply Brian.
In the meantime, i had a look at GNU Pthreads. It might be a solution
eventhough i can't figure out how come that would allow the program to
handle threads if the kernel itself doesn't support them. By 'they basically
spawn whole new full processes' do you mean that with this lib, threads are
actually processes ?
Brian K. White
> Thanks for the reply Brian.
>
> In the meantime, i had a look at GNU Pthreads. It might be a solution
> eventhough i can't figure out how come that would allow the program to
> handle threads if the kernel itself doesn't support them. By 'they
basically
> spawn whole new full processes' do you mean that with this lib, threads
are
> actually processes ?
and the answer is... "I think so"
a couple years ago I was looking at the various threads libraries because
it was a hobby of mine to build gnu apps for open server, and ghostscript
6 had become threaded, and I did get it to build using... I forget which
library now, because someone else also built it and packaged it in
skunkware so I've just been using that since then.
While I was doing that, I seem to recall that was how these libraries
worked, but today I cannot say and don't feel like looking right now, so
take it as a hint or clue as to what may be going on to keep in mind while
you look yourself.
J. L. Schilling
>
> In the meantime, i had a look at GNU Pthreads. It might be a solution
> eventhough i can't figure out how come that would allow the program to
> handle threads if the kernel itself doesn't support them.
Libraries such as GNU Pthreads are basically "user space" threads libraries
when run on OpenServer.
All of the threads exist within one user process and one kernel process.
The threads each have their own stack and their own state, with something
like getcontext()/setcontext() being used to do context switches amongst
the threads. As a result, such a library can support threading even
though the kernel doesn't have any concept of threads or light-weight
processes.
The downside is that you get no benefit from being on a multiprocessor
machine, and implementing non-blocking/asynchronous I/O is more
problematic. See
http://www.gnu.org/software/pth/pth-manual.html#the world of threading
for more.
Jonathan Schilling
Frank
We're working on a SCO OpenServer 5.0.5 and are trying to port an
application from a Mandrake Linux v.7.2.2.2.17.21.mdk (kernel version).
We seem to have different thread behaviour on these two platforms. Can
anyone tell the main differences between the threads programming and
behaviour
on both platforms?
It seems this thread has some relation to our problem.
Basically I need to know are we in trouble (1 week to deadline for this
port)?
Any pointers, help, suggestions are appriciated!
Thanks,
Frank
J. L. Schilling <jlsels...@my-deja.com> wrote in message
news:ff3c0649.0203...@posting.google.com...
Bela Lubkin
> We're working on a SCO OpenServer 5.0.5 and are trying to port an
> application from a Mandrake Linux v.7.2.2.2.17.21.mdk (kernel version).
> We seem to have different thread behaviour on these two platforms. Can
> anyone tell the main differences between the threads programming and
> behaviour
> on both platforms?
>
> It seems this thread has some relation to our problem.
> Basically I need to know are we in trouble (1 week to deadline for this
> port)?
>
> Any pointers, help, suggestions are appriciated!
Why is it that you are able to quote your Linux version number to more
than 8 digits of detail, but do not even identify which of the several
OpenServer threads implementations you are using?!
If you have a one-week deadline it would behoove you to give a lot of
details, fast. What threads implementation? (Give the URL of the
precompiled or source archive you're working with.) What differences in
behavior? (Describe. Provide a small source example if you can; making
sure that it is clear how to compile it, how to run it, how its behavior
differs, and your best theory on the cause.)
>Bela<
Frank
SCO returns after a uname -a: SCO_SV l569100 3.2 5.0.5 I386
The problem is that if we execute the code (see attachment) on the SCO
machine, it seems that what we get is:
Thread 1 executing and finishing
Thread 2 executing and finishing.
and so on upto 10.
It almost seems that this process is doing calls to a subroutine instead of
multithreading.
On Linux we see:
Ten threads starting and finishing in random order!
The threads (for test purpose) are put to sleep for ten seconds each.
Therefor ten threads on the SCO will take over 100 seconds.
On the Linux machine the whole process takes over 10 seconds (the threads
are actually 'threading')
What seems to happen is that when we "join()" the threads on SCO, the thread
takes over control and doesn't release it untill it finishes. This is highly
undesired.
Hope you can help me further!
Regards,
Frank
PS: build command: g++ multiple.cpp -o multiple -Wall -g -lpthread -lsocket
Bela Lubkin <be...@caldera.com> wrote in message
news:2002032002...@mammoth.ca.caldera.com...
Bela Lubkin
> SCO returns after a uname -a: SCO_SV l569100 3.2 5.0.5 I386
There are probably also patches installed; and this still tells us
nothing about the threads implementation you're using.
> The problem is that if we execute the code (see attachment) on the SCO
Your attachment didn't make it through the USENET news -> mail gateway
I'm using. I don't know if Xenitec stripped it or what. Next time, try
just including it as text. But I did receive the copy you sent
privately, so I'll paste the code in here:
=============================================================================
#include <iostream.h>
#include <pthread.h>
#include <unistd.h>
#include <sched.h>
#define MAX_THREAD 10
void *proc( void *i)
{
int a = (int) i;
cout << "T Hello world " << a << endl;
sleep( 10 );
cout << "T Quiting thread" << endl;
return( (void *)0 );
}
int main( void )
{
int rc;
int i;
pthread_t thread[ MAX_THREAD ];
cout << "M Creating threads" << endl;
for (i=0; i<MAX_THREAD; i++ ) {
rc = pthread_create( &thread[ i ], NULL, proc, (void *)i );
}
sleep( 10 );
cout << "M Joining threads" << endl;
for (i=0; i<MAX_THREAD; i++ ) {
pthread_join( thread[ i ], NULL );
}
return( 0 );
}
=============================================================================
> machine, it seems that what we get is:
> Thread 1 executing and finishing
> Thread 2 executing and finishing.
> and so on upto 10.
> It almost seems that this process is doing calls to a subroutine instead of
> multithreading.
>
> On Linux we see:
> Ten threads starting and finishing in random order!
Since OpenServer doesn't support threads at the kernel level, the
available threads libraries are less preemptive than on other systems.
I don't know the exact details. Possible implementations would include
no preemption at all, or some sort of timer-based preemption...
> The threads (for test purpose) are put to sleep for ten seconds each.
> Therefor ten threads on the SCO will take over 100 seconds.
> On the Linux machine the whole process takes over 10 seconds (the threads
> are actually 'threading')
... however, sleep() should completely block a thread in such a way that
the next thread should immediately be able to execute. So this seems to
me like a bug in the particular threads implementation you're using.
But I am not an experienced threads programmer, I could be missing a
subtlety.
Any particular threads implementation could, and in fact likely might,
have some sort of overall controls over the preemption model. You may
need to read the docs and/or source of the threads library you're using,
see if it mentions how to enable preemption. (But it still seems wrong
to me that calling sleep() doesn't _automatically_ lead to a preemption
event.)
> What seems to happen is that when we "join()" the threads on SCO, the thread
> takes over control and doesn't release it untill it finishes. This is highly
> undesired.
>
> Hope you can help me further!
>
> Regards,
> Frank
>
> PS: build command: g++ multiple.cpp -o multiple -Wall -g -lpthread -lsocket
Ok, this tells us that you are using some random version and build of
g++, and a threads library that calls itself "libpthread.*".
For best results you need to properly identify these items. They are
not standard parts of OSR5. Someone at your site added them, possibly
from the Caldera Skunkware site, possibly from elsewhere, including
possibly by building them from their respective open sources. Unwind
the chain and tell us what those things are and where they came from.
It's important.
>Bela<
Robert Lipe
>
> Ok, this tells us that you are using some random version and build of
> g++, and a threads library that calls itself "libpthread.*".
It seems improbable that this is the correct compilation line.
Simply sneaking a threads library into the link isn't enough to get you
a correctly threaded world. In fact, it's so unlikely to be correct that
our compilers detect this and warn about it.
Since OpenServer doesn't have "real" threads, gcc doesn't have a
'-pthread' to set the correct manifests and correct link order
for whatever threads package you might happen to be using. Search the
doc for that library for A) a manifest that you have to set and B) guidance
on the library link order. (Yes, the order DOES matter.)
J. L. Schilling
>
> We're working on a SCO OpenServer 5.0.5 and are trying to port an
> application from a Mandrake Linux v.7.2.2.2.17.21.mdk (kernel version).
> We seem to have different thread behaviour on these two platforms. Can
> anyone tell the main differences between the threads programming and
> behaviour on both platforms?
One OS supports threads and one doesn't, that's a pretty big difference!
On Linux each application thread will be a separate cloned process,
managed by Linux's threads library. You don't say what third-party
threads package you are using on OpenServer, but as stated previously
it will be trying to manage threading within one user-space process.
There's bound to be a lot of difference between these two models,
in terms of performance, preemption, reliability, scalability, etc.
> Basically I need to know are we in trouble (1 week to deadline for this
> port)?
Time to start ordering in the pizza and Cokes!
Jonathan Schilling
J. L. Schilling
>
> The problem is that if we execute the code (see attachment) on the SCO
> machine, it seems that what we get is:
> Thread 1 executing and finishing
> Thread 2 executing and finishing.
> and so on upto 10.
> It almost seems that this process is doing calls to a subroutine instead of
> multithreading.
>
> On Linux we see:
> Ten threads starting and finishing in random order!
>
> The threads (for test purpose) are put to sleep for ten seconds each.
> Therefor ten threads on the SCO will take over 100 seconds.
> On the Linux machine the whole process takes over 10 seconds (the threads
> are actually 'threading')
Nothing in your program dictates what the order of thread execution will
be. You give no priorities, supply no synchronization, etc.
On Caldera Open UNIX 8, which does have a real threads library and kernel
LWPs, the output is this (I modified your test to print out the thread
number on the Quit message):
M Creating threads
T Hello world 0
T Hello world 1
T Hello world 2
T Hello world 3
T Hello world 4
T Hello world 5
T Hello world 6
T Hello world 7
T Hello world 8
T Hello world 9
M Joining threads
T Quitting thread 0
T Quitting thread 1
T Quitting thread 2
T Quitting thread 3
T Quitting thread 4
T Quitting thread 5
T Quitting thread 6
T Quitting thread 7
T Quitting thread 8
T Quitting thread 9
which is perfectly reasonable. The wait in the middle is about 10 seconds,
which is also what you'd expect.
Now, if you stick a sched_yield() call in the proc() function right
before it does its sleep(), then you'll be more likely to get a jumbled
order:
M Creating threads
T Hello world 0
T Hello world 1
T Hello world 2
T Hello world 3
T Hello world 4
T Hello world 5
T Hello world 6
T Hello world 7
T Hello world 8
T Hello world 9
M Joining threads
T Quitting thread 0
T Quitting thread 2
T Quitting thread 4
T Quitting thread 6
T Quitting thread 8
T Quitting thread 1
T Quitting thread 3
T Quitting thread 7
T Quitting thread 5
T Quitting thread 9
But there's still no guarantee of that, given your coding. Indeed
adding a sched_yield() in front of the "Hello" message doesn't change
the order those messages come out in, at least on this system for
this run.
Jonathan Schilling
J. L. Schilling
>
> Therefor ten threads on the SCO will take over 100 seconds.
> On the Linux machine the whole process takes over 10 seconds (the threads
> are actually 'threading')
I forgot to respond to this part.
In real threads libraries, the sleep() system call and the threads library
cooperate, such that each thread is allowed to sleep independently of
the others. [See for example the sleep(2) man page on Open UNIX 8.]
I suspect what is happening to you is that whatever third-party threads
library you on using on OpenServer doesn't do this, and consequently
each thread does a 10-second wait that holds up the whole process and
hence all the other threads, adding up to 100 seconds of sleep.
This is one of the basic disadvantage of third-party user-space
threads libraries: they don't interact well with OS facilities.
Jonathan Schilling
Frank
Thank you all for your help!
I did get one of my questions answered: Yes, we're in trouble! (Pizza
delivery WILL run out of cheese!)
Oke, let's see. We're indeed using a third party thread liberary (as many of
you already told us),
what we can find is that the installation of Skunkware is available. The
version of libpthread is 1.3.5 (17 apr. 2000)
Our compiler g++ is version 2.95.2.
To complicate things, we add a new problem to our predicament: This is the
config running at the costumer site. Updating
the liberary would require 100's (a guess) of server updates. If we need to
update at all.....
So you understand that we're very reluctant to switch version of liberaries,
let alone switch OS.
So a new question pops up: Can we do we we want to do under the current
configuration?
(Your answers suggest that we can't, but let's hope my English is that bad,
that I overlooked something)
(Where heading in the direction of pthread_setschedparam(...), correct?)
If not, what updates are required (not OS)!?
(Versions of pthreads. Rather that that other products, because of update
and recoding)
Regards,
Frank
PS: hereunder is a new makefile, as was stated before the makefile plays an
important role, does anyone see any problems with it?
+++++++++++++++++MAKEFILE+++++++++++++++++++
CC=g++
CFLAGS=-Wall -g `pthread-config --cflags`
LDFLAGS=-lsocket `pthread-config --ldflags`
LIBS=-lm `pthread-config --libs`
OBJ= main.o
#the default rule
all:multiple
#linking object files
multiple: $(OBJ)
$(CC) $(LDFLAGS) -o $@ $+ $(LIBS)
#compiling source files
%.o: %.cpp
$(CC) -c $+ $(CFLAGS)
#clean up
clean:
rm -f *.o
cleanall:
make clean
rm -f multiple
Bela Lubkin <be...@caldera.com> wrote in message
news:2002032003...@mammoth.ca.caldera.com...
J. L. Schilling
>
> To complicate things, we add a new problem to our predicament: This is the
> config running at the costumer site. Updating
> the liberary would require 100's (a guess) of server updates. If we need to
> update at all.....
> So you understand that we're very reluctant to switch version of liberaries,
> let alone switch OS.
My guess is that you need to work around these problems in your application.
Changing threads libraries probably won't help much. Changing OSes would
help, but doesn't sound realistic.
> So a new question pops up: Can we do we we want to do under the current
> configuration?
> (Your answers suggest that we can't, but let's hope my English is that bad,
> that I overlooked something)
> (Where heading in the direction of pthread_setschedparam(...), correct?)
Yes, you may need to specify the scheduling. You also should avoid sleep();
using something like pthread_cond_timedwait() usually works better. You
can also put in sched_yield() calls at strategic points.
Jonathan Schilling
Frank
points!!
Although it's not exactly concurrent, it's working for our problem.
Thanks to all contributing!
J. L. Schilling <jlsels...@my-deja.com> wrote in message
news:ff3c0649.02032...@posting.google.com...