* pthread / TQM5200 problem
@ 2008-02-01 12:47 Sebastian Theiss
2008-02-01 14:56 ` Sebastian Theiss
2008-02-02 4:24 ` Wolfgang Denk
0 siblings, 2 replies; 4+ messages in thread
From: Sebastian Theiss @ 2008-02-01 12:47 UTC (permalink / raw)
To: linuxppc-dev
Hi all.
I've been having some headache using the pthread library with a TB5200 =
box
(based on a TQM5200 board with a Freescale MPC5200 PowerPC-CPU). I =
created a
small program to pin down the problem and it runs fine on all my Unix- =
and
Linux-machines but fails on the embedded box: The program contains a =
class
CSignal that provides thread-synchronisation based on the
pthread_cond_signal and pthread_cond_wait calls and takes care of the
"spurious wakeup" and "lost signal" problems. The program runs 159
additional threads (that seems to be some internal limit), each of them
continuously increments a field variable and afterwards sleeps until the
main thread wakes it up again. The main thread monitors the whole field =
of
variables that are incremented by the 159 other threads and continuously
wakes them up. When running in the desired way, the program should show =
a
table with 160 entries and each entry (except for the last) should
continuously increase. However, on the box the threads 31 to 64 never =
wake
up, once they call pthread_cond_wait. The code below lacks some error
checking to keep it short, but besides that I don't see what's going =
wrong.
And, the code runs fine on my "real" Linux machines.
Any ideas of what the problem might be and how to fix it? Your I help =
would
be greatly appreciated as I'm rather despaired right now.
Regards,
Sebastian
#include <stdio.h>
#include <pthread.h>
class CSignal
{
public:
CSignal()
{
m_bFlag =3D false;
pthread_mutex_init(&m_Mutex, NULL);
pthread_cond_init(&m_Condition, NULL);
}
~CSignal()
{
pthread_mutex_destroy(&m_Mutex);
pthread_cond_destroy(&m_Condition);
}
public:
void Set(bool bValue =3D true)
{
pthread_mutex_lock(&m_Mutex);
if( m_bFlag =3D bValue ) pthread_cond_broadcast(&m_Condition);
pthread_mutex_unlock(&m_Mutex);
}
void Wait()
{
pthread_mutex_lock(&m_Mutex);
while( !m_bFlag ) pthread_cond_wait(&m_Condition,&m_Mutex);
pthread_mutex_unlock(&m_Mutex);
}
protected:
volatile bool m_bFlag;
pthread_mutex_t m_Mutex;
pthread_cond_t m_Condition;
};
#define THREAD_COUNT 160
unsigned char state[THREAD_COUNT];
CSignal signal[THREAD_COUNT];
void* threadproc(void* pParam)
{
int index =3D (int)pParam;
while( true )
{
state[index]++;
// wait for the signal beeing set
signal[index].Wait();
// reset signal, so that next Wait() will actually case the
thread to sleep again
signal[index].Set(false);
}
}
int main()
{
// clear state field
for( int i =3D 0; i < THREAD_COUNT; i++ )
{
state[i] =3D 0;
}
// run 160 threads (creation of the last thread throws EAGAIN, so
159 (+ the main thread)=20
// seems to be some kind of limit, but that's not the point here)
for( int i =3D 0; i < THREAD_COUNT; i++ )
{
pthread_t id;
printf("create thread %i: %i\n", i, pthread_create(&id,
NULL, threadproc, (void*)i));
}
for(;;)
{
// wake all threads
for( int i =3D 0; i < THREAD_COUNT; i++ )
{
signal[i].Set();
}
// print state of each thread
printf("\033[H");
int thread =3D 0;
for( int i =3D 0; i < 16; i++ )
{
for( int j =3D 0; j < 10; j++, thread++ )
{
printf("%03i/%03i ", thread, state[thread]);
}
printf("\n");
}
}
return 0;
} =20
=20
_________________________________________________________
Technische Universit=E4t Dresden
Fakult=E4t Informatik
Institut f=FCr Angewandte Informatik
Lehrstuhl f=FCr Technische Informationssysteme
D-01062 Dresden
Besucheradresse: N=F6thnitzer Str. 46, Zi. 1079
Telefon +49 351 463-38399
Telefax +49 351 463-38460
st12@inf.tu-dresden.de
_________________________________________________________
=20
^ permalink raw reply [flat|nested] 4+ messages in thread
* pthread / TQM5200 problem
2008-02-01 12:47 pthread / TQM5200 problem Sebastian Theiss
@ 2008-02-01 14:56 ` Sebastian Theiss
2008-02-01 15:17 ` Grant Likely
2008-02-02 4:24 ` Wolfgang Denk
1 sibling, 1 reply; 4+ messages in thread
From: Sebastian Theiss @ 2008-02-01 14:56 UTC (permalink / raw)
To: linuxppc-dev
Hi,
Here's some additional information I forgot when originally posting my
question today morning: I'm using the DENX ELDK 3.1.1 and a kernel =
version
2.4.25.
Regards,
Sebastian
-----Urspr=FCngliche Nachricht-----
Von: linuxppc-dev-bounces+st12=3Dinf.tu-dresden.de@ozlabs.org
[mailto:linuxppc-dev-bounces+st12=3Dinf.tu-dresden.de@ozlabs.org] Im =
Auftrag
von Sebastian Theiss
Gesendet: Freitag, 1. Februar 2008 13:48
An: linuxppc-dev@ozlabs.org
Betreff: pthread / TQM5200 problem
Hi all.
I've been having some headache using the pthread library with a TB5200 =
box
(based on a TQM5200 board with a Freescale MPC5200 PowerPC-CPU). I =
created a
small program to pin down the problem and it runs fine on all my Unix- =
and
Linux-machines but fails on the embedded box: The program contains a =
class
CSignal that provides thread-synchronisation based on the
pthread_cond_signal and pthread_cond_wait calls and takes care of the
"spurious wakeup" and "lost signal" problems. The program runs 159
additional threads (that seems to be some internal limit), each of them
continuously increments a field variable and afterwards sleeps until the
main thread wakes it up again. The main thread monitors the whole field =
of
variables that are incremented by the 159 other threads and continuously
wakes them up. When running in the desired way, the program should show =
a
table with 160 entries and each entry (except for the last) should
continuously increase. However, on the box the threads 31 to 64 never =
wake
up, once they call pthread_cond_wait. The code below lacks some error
checking to keep it short, but besides that I don't see what's going =
wrong.
And, the code runs fine on my "real" Linux machines.
Any ideas of what the problem might be and how to fix it? Your I help =
would
be greatly appreciated as I'm rather despaired right now.
Regards,
Sebastian
#include <stdio.h>
#include <pthread.h>
class CSignal
{
public:
CSignal()
{
m_bFlag =3D false;
pthread_mutex_init(&m_Mutex, NULL);
pthread_cond_init(&m_Condition, NULL);
}
~CSignal()
{
pthread_mutex_destroy(&m_Mutex);
pthread_cond_destroy(&m_Condition);
}
public:
void Set(bool bValue =3D true)
{
pthread_mutex_lock(&m_Mutex);
if( m_bFlag =3D bValue ) pthread_cond_broadcast(&m_Condition);
pthread_mutex_unlock(&m_Mutex);
}
void Wait()
{
pthread_mutex_lock(&m_Mutex);
while( !m_bFlag ) pthread_cond_wait(&m_Condition,&m_Mutex);
pthread_mutex_unlock(&m_Mutex);
}
protected:
volatile bool m_bFlag;
pthread_mutex_t m_Mutex;
pthread_cond_t m_Condition;
};
#define THREAD_COUNT 160
unsigned char state[THREAD_COUNT];
CSignal signal[THREAD_COUNT];
void* threadproc(void* pParam)
{
int index =3D (int)pParam;
while( true )
{
state[index]++;
// wait for the signal beeing set
signal[index].Wait();
// reset signal, so that next Wait() will actually case the
thread to sleep again
signal[index].Set(false);
}
}
int main()
{
// clear state field
for( int i =3D 0; i < THREAD_COUNT; i++ )
{
state[i] =3D 0;
}
// run 160 threads (creation of the last thread throws EAGAIN, so
159 (+ the main thread)=20
// seems to be some kind of limit, but that's not the point here)
for( int i =3D 0; i < THREAD_COUNT; i++ )
{
pthread_t id;
printf("create thread %i: %i\n", i, pthread_create(&id,
NULL, threadproc, (void*)i));
}
for(;;)
{
// wake all threads
for( int i =3D 0; i < THREAD_COUNT; i++ )
{
signal[i].Set();
}
// print state of each thread
printf("\033[H");
int thread =3D 0;
for( int i =3D 0; i < 16; i++ )
{
for( int j =3D 0; j < 10; j++, thread++ )
{
printf("%03i/%03i ", thread, state[thread]);
}
printf("\n");
}
}
return 0;
} =20
=20
_________________________________________________________
Technische Universit=E4t Dresden
Fakult=E4t Informatik
Institut f=FCr Angewandte Informatik
Lehrstuhl f=FCr Technische Informationssysteme
D-01062 Dresden
Besucheradresse: N=F6thnitzer Str. 46, Zi. 1079
Telefon +49 351 463-38399
Telefax +49 351 463-38460
st12@inf.tu-dresden.de
_________________________________________________________
=20
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: pthread / TQM5200 problem
2008-02-01 14:56 ` Sebastian Theiss
@ 2008-02-01 15:17 ` Grant Likely
0 siblings, 0 replies; 4+ messages in thread
From: Grant Likely @ 2008-02-01 15:17 UTC (permalink / raw)
To: Sebastian Theiss; +Cc: linuxppc-dev
On 2/1/08, Sebastian Theiss <st12@inf.tu-dresden.de> wrote:
> Hi,
>
> Here's some additional information I forgot when originally posting my
> question today morning: I'm using the DENX ELDK 3.1.1 and a kernel version
> 2.4.25.
Ugh. You might have trouble getting support on this list. Almost
everyone here is firmly focused on the 2.6 kernel. Can you upgrade to
a recent kernel version. 2.6.24 is looking really good for mpc5200
work.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: pthread / TQM5200 problem
2008-02-01 12:47 pthread / TQM5200 problem Sebastian Theiss
2008-02-01 14:56 ` Sebastian Theiss
@ 2008-02-02 4:24 ` Wolfgang Denk
1 sibling, 0 replies; 4+ messages in thread
From: Wolfgang Denk @ 2008-02-02 4:24 UTC (permalink / raw)
To: Sebastian Theiss; +Cc: linuxppc-dev
In message <002c01c864d0$a4ad11c0$0101a8c0@tis> you wrote:
>
> I've been having some headache using the pthread library with a TB5200 box
> (based on a TQM5200 board with a Freescale MPC5200 PowerPC-CPU). I created a
> small program to pin down the problem and it runs fine on all my Unix- and
NOTE: It is really bad behaviour to post the same question indepen-
dently in several mailing list. Your question has already been
answered on the ELDK list.
> Linux-machines but fails on the embedded box: The program contains a class
> CSignal that provides thread-synchronisation based on the
> pthread_cond_signal and pthread_cond_wait calls and takes care of the
> "spurious wakeup" and "lost signal" problems. The program runs 159
> additional threads (that seems to be some internal limit), each of them
And this strange "internal limit" is an indication that you are
running code that is more than 1.5 years old, as the bug was fixed in
September 2006. It was caused by bad PCI mappings that overlap with
CONFIG_TASKSIZE.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
It would seem that evil retreats when forcibly confronted
-- Yarnek of Excalbia, "The Savage Curtain", stardate 5906.5
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2008-02-02 4:24 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-02-01 12:47 pthread / TQM5200 problem Sebastian Theiss
2008-02-01 14:56 ` Sebastian Theiss
2008-02-01 15:17 ` Grant Likely
2008-02-02 4:24 ` Wolfgang Denk
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).