_begiinthread

QNX Newsgroups (Archives) qnx.qnx4
1

Hi,

When I’m trying to launch another thread by _beginthread from a running
thread (that is also created by _beginthread) I always find that
_beginthread fails with ENOMEM. Also, after creating a thread by
_beginthread I find that my memory allocation of 8K fails.The code for
_beginthread is taken from the sample QNX doc. Any idea on what I’m missing?

Thanks,
Hakim

2

Hakim <ddrv2002@yahoo.ca> wrote:

Hi,

When I’m trying to launch another thread by _beginthread from a running
thread (that is also created by _beginthread) I always find that
_beginthread fails with ENOMEM. Also, after creating a thread by
_beginthread I find that my memory allocation of 8K fails.The code for
_beginthread is taken from the sample QNX doc. Any idea on what I’m missing?

As a general rule I recommend against trying to use any of the threading
pieces in QNX4. (And, please note that the QNX thread model is not
a POSIX threads model.)

I recommend cooperating processes, using shared memory if they need to
share data, rather than any of the threading stuff. It works more reliably,
and consistently, and there is little (if anything) that threading gives
you over this model.

So, on the ENOMEM – first are you out of system memory? If you are, then
that would explain it. If not, I don’t know what else might be causing
it in this situation. Do you have a (smallish) sample that demonstrates
what’s going wrong? i.e. your modifications to the QNX doc example.

So, back to why threads? Why are you trying to use threads? What problem are
you trying to solve, that you think threading will help with?

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com

3

So, back to why threads? Why are you trying to use threads? What problem
are
you trying to solve, that you think threading will help with?

I have a QNX6 driver that I need to port to QNX4. QNX6 driver uses pthread
stuff, so the equivalent I found is _beginthread_endthread etc.

So, on the ENOMEM – first are you out of system memory? If you are, then
that would explain it.

The system has 192MB system memory, very minimum service is loaded, I can
find the free memory but I’m sure it has lots of MB.

I recommend cooperating processes, using shared memory if they need to
share data, rather than any of the threading stuff. It works more
reliably,
and consistently, and there is little (if anything) that threading gives
you over this model.

OK, I’ll be using traditional process stuff.

Thanks,
Hakim


“David Gibbs” <dagibbs@qnx.com> wrote in message
news:d7q94e$mp0$2@inn.qnx.com…

Hakim <> ddrv2002@yahoo.ca> > wrote:
Hi,

When I’m trying to launch another thread by _beginthread from a running
thread (that is also created by _beginthread) I always find that
_beginthread fails with ENOMEM. Also, after creating a thread by
_beginthread I find that my memory allocation of 8K fails.The code for
_beginthread is taken from the sample QNX doc. Any idea on what I’m
missing?

As a general rule I recommend against trying to use any of the threading
pieces in QNX4. (And, please note that the QNX thread model is not
a POSIX threads model.)

I recommend cooperating processes, using shared memory if they need to
share data, rather than any of the threading stuff. It works more
reliably,
and consistently, and there is little (if anything) that threading gives
you over this model.

So, on the ENOMEM – first are you out of system memory? If you are, then
that would explain it. If not, I don’t know what else might be causing
it in this situation. Do you have a (smallish) sample that demonstrates
what’s going wrong? i.e. your modifications to the QNX doc example.

So, back to why threads? Why are you trying to use threads? What problem
are
you trying to solve, that you think threading will help with?

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com

4

Hakim <ddrv2002@yahoo.ca> wrote:

So, back to why threads? Why are you trying to use threads? What problem
are
you trying to solve, that you think threading will help with?

I have a QNX6 driver that I need to port to QNX4. QNX6 driver uses pthread
stuff, so the equivalent I found is _beginthread_endthread etc.

Ah, back-porting a QNX6 driver. Hm.

QNX6 has some nice things, like interchangeability of threads for QNX
IPC, i.e. if thread 1 in a process receives a message, then thread 3
could reply to it, or vice versa. QNX 4 does not have this. And, most
drivers work (at least to some extent) at the QNX message level.

QNX4’s threads aren’t really threads – they are two seperate processes
that share the same code and data. This results in very different
behaviours.

I don’t know exactly how your QNX 6 driver is structured, but I can
see two main ways I’d suggest for porting it back to QNX4:

  1. do it all single threaded in one process. Use a Receive() as a
    common blocking point for both proxies from interrupt handlers and
    messages from clients. Make sure that nowhere in your code do you
    spend too much (based on hw latencies) blocked or doing something,
    so you can get back to that Receive() loop.

  2. do it as 2 processes. Put the hw handling in one process, and the
    client handling in another process. Use shared memory between the
    two process, with semaphores for locking, and proxies for wakeup.
    Everything exchanged as “global” data between the threads in the
    QNX6 driver would be stuck in the shared memory between the QNX4
    driver halves.

If this driver was a resource manager, then porting to an I/O
manager framework will be a whole different issue. It is a lot
trickier to do one under QNX4 – we made it a lot easier under
QNX6.

So, on the ENOMEM – first are you out of system memory? If you are, then
that would explain it.

The system has 192MB system memory, very minimum service is loaded, I can
find the free memory but I’m sure it has lots of MB.

Yeah, sounds like something strange in the “threading” stuff, then. You
shouldn’t have run out of memory, likely.

I recommend cooperating processes, using shared memory if they need to
share data, rather than any of the threading stuff. It works more
reliably,
and consistently, and there is little (if anything) that threading gives
you over this model.

OK, I’ll be using traditional process stuff.

I think you’ll find it easier, too. Maybe a bit more porting work,
but far less debugging and strange limitations problems. (Another
issue you’ll be avoiding – much of the C library under QNX6 was thread
safe, while much under QNX4 was not.)

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com

5

Thanks for the nice feedback.
The driver is indeed resource manager and hardwareless.
It would be nice to have _beginthread worked. I’ll have to prepare a fresh
new project plan for the added complexity.

Thanks,
Hakim

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:d7qd1a$pj5$1@inn.qnx.com…

Hakim <> ddrv2002@yahoo.ca> > wrote:
So, back to why threads? Why are you trying to use threads? What
problem
are
you trying to solve, that you think threading will help with?

I have a QNX6 driver that I need to port to QNX4. QNX6 driver uses
pthread
stuff, so the equivalent I found is _beginthread_endthread etc.

Ah, back-porting a QNX6 driver. Hm.

QNX6 has some nice things, like interchangeability of threads for QNX
IPC, i.e. if thread 1 in a process receives a message, then thread 3
could reply to it, or vice versa. QNX 4 does not have this. And, most
drivers work (at least to some extent) at the QNX message level.

QNX4’s threads aren’t really threads – they are two seperate processes
that share the same code and data. This results in very different
behaviours.

I don’t know exactly how your QNX 6 driver is structured, but I can
see two main ways I’d suggest for porting it back to QNX4:

  1. do it all single threaded in one process. Use a Receive() as a
    common blocking point for both proxies from interrupt handlers and
    messages from clients. Make sure that nowhere in your code do you
    spend too much (based on hw latencies) blocked or doing something,
    so you can get back to that Receive() loop.

  2. do it as 2 processes. Put the hw handling in one process, and the
    client handling in another process. Use shared memory between the
    two process, with semaphores for locking, and proxies for wakeup.
    Everything exchanged as “global” data between the threads in the
    QNX6 driver would be stuck in the shared memory between the QNX4
    driver halves.

If this driver was a resource manager, then porting to an I/O
manager framework will be a whole different issue. It is a lot
trickier to do one under QNX4 – we made it a lot easier under
QNX6.

So, on the ENOMEM – first are you out of system memory? If you are,
then
that would explain it.

The system has 192MB system memory, very minimum service is loaded, I can
find the free memory but I’m sure it has lots of MB.

Yeah, sounds like something strange in the “threading” stuff, then. You
shouldn’t have run out of memory, likely.

I recommend cooperating processes, using shared memory if they need to
share data, rather than any of the threading stuff. It works more
reliably,
and consistently, and there is little (if anything) that threading gives
you over this model.

OK, I’ll be using traditional process stuff.

I think you’ll find it easier, too. Maybe a bit more porting work,
but far less debugging and strange limitations problems. (Another
issue you’ll be avoiding – much of the C library under QNX6 was thread
safe, while much under QNX4 was not.)

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com

6

Hakim <ddrv2002@yahoo.ca> wrote:

Thanks for the nice feedback.
The driver is indeed resource manager and hardwareless.

Have you downloaded the iomanager sample framework from ftp.qnx.com?

ftp.qnx.com/usr/free/qnx4/os/samples/misc/iomanager.tgz
ftp.qnx.com/usr/free/qnx4/os/samples/misc/iomanager2.tgz

And Rober Krten’s Getting Started With QNX4 has a 40 page chapter
on writing QNX4 resource managers that might also be helpful.

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com

7

Thanks for the resource tips.

Hakim

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:d81mpu$59m$2@inn.qnx.com…

Hakim <> ddrv2002@yahoo.ca> > wrote:
Thanks for the nice feedback.
The driver is indeed resource manager and hardwareless.

Have you downloaded the iomanager sample framework from ftp.qnx.com?

ftp.qnx.com/usr/free/qnx4/os/samples/misc/iomanager.tgz
ftp.qnx.com/usr/free/qnx4/os/samples/misc/iomanager2.tgz

And Rober Krten’s Getting Started With QNX4 has a 40 page chapter
on writing QNX4 resource managers that might also be helpful.

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com