[cgl_discussion] Question for TEMs/ISVs/OEMs regarding pthrea
jack.li at intel.com
Fri Jan 24 01:02:08 PST 2003
I am back from ZTE today. Actually no much updates. ZTE's CDMA2000 BTS
project currently use VxWorks, which does not have thread entity. ZTE
implement their own thread mechanism. But those threads do not share
anything in order to improve the performance. So there is no need for
Another NMC project in ZTE use thread, but that is in J2EE. Which is a
database connection pool, each thread maintain a database connection. But
ZTE's NMC applicaiton cannot control the behavior of those thread. And we
don't know the implementation detail of the database connection pool.
Sorry for cannot helping you.
> -----Original Message-----
> From: Perez-Gonzalez, Inaky
> Sent: Thursday, January 23, 2003 8:23 AM
> To: cgl discussion
> Subject: [cgl_discussion] Question for TEMs/ISVs/OEMs
> regarding pthread
> Hi All
> I am working on pthread related issues in the Linux kernel, and in one
> discussion and subsequent hair pulling to evaluate the
> consequences, it came
> to me that I needed to know what the TEMs, OEMs, and ISVs working on
> middleware and/or applications need from a pthreads package.
> More specifically, I need to know what are the realtime
> requirements of a
> pthreads package regarding mutex protocols. POSIX specifies
> three priority
> protocols, PRIO_NONE, PRIO_PROTECT and PRIO_INHERIT. Does
> anybody know or
> rely on the three of them and extensively require, for example,
> It'd be really nice if this could be passed down to
> architects/engineers who
> could shed some light into it ...
> PS: PRIO_NONE offers no support for priority-inversion problems,
> PRIO_PROTECT offers a kind of limited protection by enforcing certain
> priorities in order to acquire a mutex. PRIO_INHERIT is the
> most "advanced"
> one, and relies on bumping up the priority of a
> process/thread that has
> acquired a mutex and is blocking a higher priority process or thread.
> Inaky Perez-Gonzalez -- Not speaking for Intel - opinions are
> my own [or my
More information about the cgl_discussion