linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* 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).