[ECOS] pthread version of cyg_thread_delay

[ECOS] pthread version of cyg_thread_delay

[Tyler Wilson]

In a previous thread I started here on the list, asking about the
synthetic target, it was suggested a better approach might be to use the
POSIX threads compatibility layer in eCos, and write to that. This would
allow the application code to be the same for both eCos and Linux - and
potentially Windows with pthreads-win32 (if it works).

As a starting point I thought it would be useful to do a simple port of
the 'twothreads' example to a POSIX threads version, which I call it
'twopthreads' - original, ugh.

One item I have run in to, not being a pthreads expert, is what the
POSIX equivilant of cyg_thread_delay might be. There is a pthread_yield
type call, but there is no way to give it some time value, and have the
system do the proper thing in the background.

I have tried using nanosleep, but it results in some odd behavior - some
sort of SIGTRAP occurs when I use it. I have also tried to use
cyg_thread_delay directly, but that did not work either.

So, any examples or pointers to a pthread-friendly way to perform a
delay within a thread function?

Thank you,
Tyler 

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] pthread version of cyg_thread_delay

[Laurie Gellatly]

Tyler,
A quick google suggests that others have found 'select' as a possible 
solution.

Another approach might be to use #define to for OS specific calls.
Then you can use similar functionality that is OS dependant.

			...Laurie:{)

> -----Original Message-----
> From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-
> owner@ecos.sourceware.org] On Behalf Of Tyler Wilson
> Sent: Thursday, 13 November 2008 1:42 PM
> To: ecos-discuss@ecos.sourceware.org
> Subject: [ECOS] pthread version of cyg_thread_delay
> 
> In a previous thread I started here on the list, asking about the
> synthetic target, it was suggested a better approach might be to use
> the
> POSIX threads compatibility layer in eCos, and write to that. This
> would
> allow the application code to be the same for both eCos and Linux - and
> potentially Windows with pthreads-win32 (if it works).
> 
> As a starting point I thought it would be useful to do a simple port of
> the 'twothreads' example to a POSIX threads version, which I call it
> 'twopthreads' - original, ugh.
> 
> One item I have run in to, not being a pthreads expert, is what the
> POSIX equivilant of cyg_thread_delay might be. There is a pthread_yield
> type call, but there is no way to give it some time value, and have the
> system do the proper thing in the background.
> 
> I have tried using nanosleep, but it results in some odd behavior -
> some
> sort of SIGTRAP occurs when I use it. I have also tried to use
> cyg_thread_delay directly, but that did not work either.
> 
> So, any examples or pointers to a pthread-friendly way to perform a
> delay within a thread function?
> 
> Thank you,
> Tyler
> 
> --
> Before posting, please read the FAQ:
> http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] pthread version of cyg_thread_delay

[Nick Garnett]

"Tyler Wilson" <TWilson@ugobe.com> writes:

> In a previous thread I started here on the list, asking about the
> synthetic target, it was suggested a better approach might be to use the
> POSIX threads compatibility layer in eCos, and write to that. This would
> allow the application code to be the same for both eCos and Linux - and
> potentially Windows with pthreads-win32 (if it works).
> 
> As a starting point I thought it would be useful to do a simple port of
> the 'twothreads' example to a POSIX threads version, which I call it
> 'twopthreads' - original, ugh.
> 
> One item I have run in to, not being a pthreads expert, is what the
> POSIX equivilant of cyg_thread_delay might be. There is a pthread_yield
> type call, but there is no way to give it some time value, and have the
> system do the proper thing in the background.
> 
> I have tried using nanosleep, but it results in some odd behavior - some
> sort of SIGTRAP occurs when I use it. I have also tried to use
> cyg_thread_delay directly, but that did not work either.

nanosleep() is what you should be using, at its core it does exactly
the same thing as cyg_thread_delay(). It certainly shouldn't cause
any traps or other issues unless there are other problems with the
program or configuration.

The fact that cyg_thread_delay() also fails suggests that something
fundamental is failing. Check that you start in main() and not
cyg_user_start(), check that you haven't reduced the stack size. Make
sure you are using the posix template.


Be careful relying on POSIX to give you portability. Neither eCos,
Linux nor Windows fully implement the whole POSIX specification
perfectly. A relatively simple subset should work, but don't rely on
more subtle behaviours, particularly regarding signals, cancellation,
and other asynchronous actions to be the same between them.


-- 
Nick Garnett                                      eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com      The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.     Tel: +44 1223 245571
Registered in England and Wales:                        Reg No: 4422071


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] pthread version of cyg_thread_delay

[Tyler Wilson]

Nick,

Thank you, this is just what I was looking for - that I was not barking
up the wrong tree, so to speak. So at least now I can focus on
configuration issues, and not the core application code. Though it would
still be useful if somebody could review my use of the pthreads library
(it works okay on pthreads-win32, but only one thread runs on eCos).

And I do understand that we should not depend on the exact same behavior
between platforms. I am looking for the most basic thread support:
create a thread, yield within a thread, use mutexes or semaphores for
data access locking, etc.

Thank you,
Tyler Wilson
Ugobe, Inc.
Eagle, ID

> -----Original Message-----
> From: nickg@xl5.calivar.com [mailto:nickg@xl5.calivar.com] On Behalf
Of
> Nick Garnett
> Sent: Thursday, November 13, 2008 5:48 AM
> To: Tyler Wilson
> Cc: ecos-discuss@ecos.sourceware.org
> Subject: Re: [ECOS] pthread version of cyg_thread_delay
> 
> "Tyler Wilson" <TWilson@ugobe.com> writes:
> 
> > In a previous thread I started here on the list, asking about the
> > synthetic target, it was suggested a better approach might be to use
> the
> > POSIX threads compatibility layer in eCos, and write to that. This
> would
> > allow the application code to be the same for both eCos and Linux -
> and
> > potentially Windows with pthreads-win32 (if it works).
> >
> > As a starting point I thought it would be useful to do a simple port
> of
> > the 'twothreads' example to a POSIX threads version, which I call it
> > 'twopthreads' - original, ugh.
> >
> > One item I have run in to, not being a pthreads expert, is what the
> > POSIX equivilant of cyg_thread_delay might be. There is a
> pthread_yield
> > type call, but there is no way to give it some time value, and have
> the
> > system do the proper thing in the background.
> >
> > I have tried using nanosleep, but it results in some odd behavior -
> some
> > sort of SIGTRAP occurs when I use it. I have also tried to use
> > cyg_thread_delay directly, but that did not work either.
> 
> nanosleep() is what you should be using, at its core it does exactly
> the same thing as cyg_thread_delay(). It certainly shouldn't cause
> any traps or other issues unless there are other problems with the
> program or configuration.
> 
> The fact that cyg_thread_delay() also fails suggests that something
> fundamental is failing. Check that you start in main() and not
> cyg_user_start(), check that you haven't reduced the stack size. Make
> sure you are using the posix template.
> 
> 
> Be careful relying on POSIX to give you portability. Neither eCos,
> Linux nor Windows fully implement the whole POSIX specification
> perfectly. A relatively simple subset should work, but don't rely on
> more subtle behaviours, particularly regarding signals, cancellation,
> and other asynchronous actions to be the same between them.
> 
> 
> --
> Nick Garnett                                      eCos Kernel
Architect
> eCosCentric Limited    http://www.eCosCentric.com      The eCos
experts
> Barnwell House, Barnwell Drive, Cambridge, UK.     Tel: +44 1223
245571
> Registered in England and Wales:                        Reg No:
4422071


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss