Why so many Phidget threads?

Supporting 2.6 and up
Ironphase
Fresh meat
Posts: 3
Joined: Tue May 21, 2013 1:40 pm
Contact:

Why so many Phidget threads?

Postby Ironphase » Tue May 21, 2013 2:16 pm

I am new to phidget programming and I was not able to find a previous posting addressing this issue.
After developing a bit on my r-pi with a phidget interface kit and accelerometer, I noticed that every
phidget device added with an _open() call triggers a new thread. This is a bit worrisome for my because I am planning to add a lot of devices. Does that mean I am going to have 12 or more threads generated after opening 12 devices?

Ideally I would like to keep the number of threads low and close to the number of hardware threads supported. I already have the main engine loop for the application written and just like the architecture of a typical game engine, I would like to devote one thread to the physical hardware, sensor reading, attribute settings and the other threads left to AI and more useful stuff.

Is there a way to open the phidget devices and controlling the polling of data directly without triggering extra threads?

Thanks

User avatar
Patrick
Lead Developer
Posts: 3099
Joined: Mon Jun 20, 2005 8:46 am
Location: Canada
Contact:

Re: Why so many Phidget threads?

Postby Patrick » Tue May 21, 2013 2:44 pm

No, each opened device will have 2 associated threads.

-Patrick

Ironphase
Fresh meat
Posts: 3
Joined: Tue May 21, 2013 1:40 pm
Contact:

Re: Why so many Phidget threads?

Postby Ironphase » Tue May 21, 2013 3:07 pm

Ouchy!

User avatar
Patrick
Lead Developer
Posts: 3099
Joined: Mon Jun 20, 2005 8:46 am
Location: Canada
Contact:

Re: Why so many Phidget threads?

Postby Patrick » Tue May 21, 2013 4:08 pm

why so afraid of threads? We have never found this to be an issue performance-wise.

-Patrick

Ironphase
Fresh meat
Posts: 3
Joined: Tue May 21, 2013 1:40 pm
Contact:

Re: Why so many Phidget threads?

Postby Ironphase » Tue May 21, 2013 8:20 pm

I guess I am going to find out soon. But yes, I had performance concerns.

chal3oye
Fresh meat
Posts: 1
Joined: Wed Jan 29, 2014 1:27 am
Contact:

Re: Why so many Phidget threads?

Postby chal3oye » Wed Jan 29, 2014 2:22 am

After developing a bit on my r-pi with a phidget interface kit and accelerometer, I noticed that every
phidget device added with an _open() call triggers a new thread. This is a bit worrisome for my because I am planning to add a lot of devices. Does that mean I am going to have 12 or more threads generated after opening 12 devices?

Ideally I would like to keep the number of threads low and close to the number of hardware threads supported. I already have the main engine loop for the application written and just like the architecture of a typical game engine, I would like to devote one thread to the physical hardware, sensor reading, attribute settings and the other threads left to AI and more useful stuff.

frodegill
Phidget Mastermind
Posts: 114
Joined: Thu Mar 04, 2010 2:51 am
Contact:

Re: Why so many Phidget threads?

Postby frodegill » Wed Jan 29, 2014 3:52 am

As Patrick already said: Why this worry about number of threads? Threads share memory, and context switching them is fairly low-cost. Whenever I have a choice of non-blocking calls in a single thread or blocking call in a thread of its own, I will always opt for the latter. I have applications with 100+ threads (and for that matter, OpenCL-code with 25.000+ threads) running without any problems. Depending on your language of choice, handling concurrency and deadlocks may be a pain, but so are non-blocking calls when you have lots of them..

aleksander0m
Phidgetsian
Posts: 8
Joined: Fri Apr 10, 2015 2:19 am
Contact:

Re: Why so many Phidget threads?

Postby aleksander0m » Fri Apr 10, 2015 4:38 am

Patrick wrote:why so afraid of threads? We have never found this to be an issue performance-wise.


For simple programs, a single-threaded application with an event loop (e.g. provided by libevent or glib or the like) is 99.9% more than enough, and much less error prone, as there would be 0 threading issues. If I need asynchronicity for a program I would very likely choose a single thread with an event loop instead of multiple threads.

The problem of using threads in a library like this is that you're forcing every user of the library to be thread-aware. E.g. (if I'm not mistaken!) callbacks executed for attach/detach events aren't run on the primary program thread, but in different threads created internally by libphidget (I spent some time printing thread ids yesterday and that's what I saw, at least).

My program using libphidget is a big one, but the libphidget usage is just a very very small part of it, and now I need to take care of threading issues just for that. And mixing threads that one can not control with an already existing main loop is a nightmare, so now I'm stuck with my custom async methods which run the blocking methods of libphidget (e.g. CPhidget_waitForAttachment) instead of the async logic (e.g. attach/detach handlers) from libphidget.

If the threads were truly an internal thing (e.g. lots of GLib/GIO async methods use threads internally but still they report completion on the main thread) then that would be much easier to handle. But fair enough, preparing an async API which doesn't use threads and doesn't use any other explicit event-loop implementation is hard.

User avatar
Patrick
Lead Developer
Posts: 3099
Joined: Mon Jun 20, 2005 8:46 am
Location: Canada
Contact:

Re: Why so many Phidget threads?

Postby Patrick » Fri Apr 10, 2015 11:33 am

Something that we could do is introduce a method which users must run periodically, which will then run any pending events (ie CPhidget_runEvents() ) - this would let you use events, without having to worry about threading, even though the library would continue to use threads internally. I'm just not sure how much value this would add.

-Patrick

aleksander0m
Phidgetsian
Posts: 8
Joined: Fri Apr 10, 2015 2:19 am
Contact:

Re: Why so many Phidget threads?

Postby aleksander0m » Fri Apr 10, 2015 11:53 am

Patrick wrote:Something that we could do is introduce a method which users must run periodically, which will then run any pending events (ie CPhidget_runEvents() ) - this would let you use events, without having to worry about threading, even though the library would continue to use threads internally. I'm just not sure how much value this would add.


That would be useful only if the library also exports some common way to poll() for events being available; e.g. a pollable fd that can be integrated as an event in any kind of event loop support library like libevent or glib.


Return to “Linux”

Who is online

Users browsing this forum: No registered users and 1 guest