Unix Programming - Common code among main executable and shared objects

Author

Common code among main executable and shared objects

Bhawna

2008-01-29, 4:38 am

Hi,

We are using a multithreaded application which has a few dynamic
shared objects associated with it. We are running it on Linux
platform. Few of the classes and code part is common among main
executable and other DSOs. The DSOs have been linked using linker
option -Bsymbolic and so are able to keep their seperate objects for
common classes.

The issue we are having is we want to keep a true singleton of the
common class without disturbing current linker option. For this
purpose, we are allocating a new TLS key and putting this key into
environment, so that once initialised same object is used among all
DSOs.

The simplified design of the class can be considered as follows

class singleton{

Bhawna

2008-01-29, 4:38 am

Sorry for an incomplte post please find complete details below.

Hi,

We are using a multithreaded application which has a few dynamic
shared objects associated with it. We are running it on Linux
platform. Few of the classes and code part is common among main
executable and other DSOs. The DSOs have been linked using linker
option -Bsymbolic and so are able to keep their seperate objects for
common classes.

The issue we are having is we want to keep a true singleton of the
common class without disturbing current linker option. For this
purpose, we are allocating a new TLS key and putting this key into
environment, so that once initialised same object is used among all
DSOs.

The simplified design of the class can be considered as follows

class singleton{
static singleton* pSingleton;
static singletonMutex& getMutex() {
static singletonMutex theMutex;
return theMutex;
}

....

//globally define
static singleton* singleton::pSingleton=NULL;

....

The Mutex is used to lock all the logic which insantiates pSingleton
and pSingleton is instiated to a new object if there is the Env var is
found to NULL (using getenv). Otherwise env variable is invoked to get
a the TLS key index and instantiate pSingleton with already existing
object.

Anyhow the control always flows within code part to create new key.
Please send me the limitations of getenv or putenv in this scenario.
Or is anybody suspicious about Mutex being used incorrectly as they
are also specific to DSO.

Please let me know if you need more details on this.

Thanks and Regards
Bhawna

ppi

2008-01-29, 7:26 pm

On Jan 29, 4:53 am, Bhawna <bvnbh...@gmail.com> wrote:

>
> The issue we are having is we want to keep a true singleton of the
> common class without disturbing current linker option. For this
> purpose, we are allocating a new TLS key and putting this key into
> environment, so that once initialised same object is used among all
> DSOs.
>
> The simplified design of the class can be considered as follows
>
> class singleton{
> static singleton* pSingleton;
> static singletonMutex& getMutex() {
> static singletonMutex theMutex;
> return theMutex;
> }
>
> ...
>
> //globally define
> static singleton* singleton::pSingleton=NULL;

I think you would have better luck in a c++ related group, there is
not much code to analyze regarding the reinitialization of static
singletonMutex and the the singleton itself. You would better have a
look at this article to make sure that you not overlooked any
potential issue with these guys ;-):
http://www.aristeia.com/Papers/DDJ_...004_revised.pdf

>
> ...
>
> The Mutex is used to lock all the logic which insantiates pSingleton
> and pSingleton is instiated to a new object if there is the Env var is
> found to NULL (using getenv). Otherwise env variable is invoked to get
> a the TLS key index and instantiate pSingleton with already existing
> object.

Well, I don't the see the code that does that so I suppose there is
some kind of lock preventing races when checking for the env variable.
I don't see why the env variable is better than any other other kind
storage you could do in the process though. You may have the same
kind of issues as the ones listed in the previous article.

Cheers,
Paulo

Bhawna

2008-01-30, 4:34 am

On Jan 29, 10:31=A0pm, ppi <vod...@gmail.com> wrote:
> On Jan 29, 4:53 am, Bhawna <bvnbh...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
> I think you would have better luck in a c++ related group, there is
> not much code to analyze regarding the reinitialization of static
> singletonMutex and the the singleton itself. You would better have a
> look at this article to make sure that you not overlooked any
> potential issue with these guys ;-):http://www.aristeia.com/Papers/DDJ_Jul=
_Aug_2004_revised.pdf
>
>
>
>
>
> Well, I don't the see the code that does that so I suppose there is
> some kind of lock preventing races when checking for the env variable.
> I don't see why the env variable is better than any other other kind
> storage you could do in the process though. You =A0may have the same
> kind of issues as the ones listed in the previous article.
>
> Cheers,
> Paulo- Hide quoted text -
>
> - Show quoted text -

Thanks a lot for your answer. It was a good article. Anyways I was
able to narrow down the svope of my problem and so I would rephrase my
problem. And because the problem had more to do with linux threads,
DSOs I chose to write it on Unix forum rather than c++.

More specific problem definition is as it follows.

We are using a multithreaded application which has a few dynamic
shared objects associated with it. We are running it on Linux
platform. Few of the classes and code part is common among main
executable and other DSOs. The DSOs have been linked using linker
option -Bsymbolic and so are able to keep their seperate objects for
common classes.

The issue we are having is we want to keep a true singleton of the
common class without disturbing current linker option. For this
purpose, we are allocating a new TLS key and putting this key into
environment, so that once initialised same object is used among all
DSOs. Based on what I read in man pages of pthread_key_create,
pthread_setspecific and pthread_getspecific, I can create a key as an
opaque object among multiple threads, but the values will still be
thread specific.

My specific questions in this scenario is:
1. Can I use TLS key-value pair common among multiple threads of an
application? If yes, can anybody please provide me any link to help me
on this?
2. Is there any other approach I can use to ensure that I have a
common object being shared among multiple threads belonging to
different DSOs, inspite of using -Bsymbolic linker option with DSOs?
3. Or is there any way to override the effect of -Bsymbolic linker
option for some specific symbols in any DSO, so as to ensure existence
of common symbols.

Any help in this regard willl be greatly appreciated.

Thanks and Regards
Bhawna

Sponsored Links