correct approach to fix a bug

[bob]

Hi,

We are having a resource issue with our legacy codebase that involves
use of semaphores (in summary we use custom containers in an abstract
base class. Each uses 2 semaphores which causes lots of handles to be
consumed on windoze). when the application is under heavy load, we have
a lot of these containers, and thus semaphores being instantiated.
Eventually Bill Gates bombs out when no more handles are available. God
bless his soul.


Looking at the code, we see that the containers are instantiated in an
abstract base class. The obvious thing to do in this case is to move
the containers down into the non-abstract classes so we reduce the
number of times a container is instantiated (not all derived classes
need the containers and thus the semaphores) and so we'll save on the
number of semaphores consumed by the OS.

I'd like to know if there's a known c++ design approach that can be
adopted in this case. Is there any technique or strategy that is known
and can be generally applied in this kind of scenario. Its the design
rather than the detail (obviously, as I've given no detail ) that
interests me in this case.


Hope I've posted enough info. If not I'll add as needed.

have a nice day.

grahamO

 

[Jeffrey Baker]

Hi,

We are having a resource issue with our legacy codebase that involves
use of semaphores (in summary we use custom containers in an abstract
base class. Each uses 2 semaphores which causes lots of handles to be
consumed on windoze). when the application is under heavy load, we have
a lot of these containers, and thus semaphores being instantiated.
Eventually Bill Gates bombs out when no more handles are available. God
bless his soul.


Looking at the code, we see that the containers are instantiated in an
abstract base class. The obvious thing to do in this case is to move
the containers down into the non-abstract classes so we reduce the
number of times a container is instantiated (not all derived classes
need the containers and thus the semaphores) and so we'll save on the
number of semaphores consumed by the OS.

I'd like to know if there's a known c++ design approach that can be
adopted in this case. Is there any technique or strategy that is known
and can be generally applied in this kind of scenario. Its the design
rather than the detail (obviously, as I've given no detail ) that
interests me in this case.


Hope I've posted enough info. If not I'll add as needed.

have a nice day.

grahamO

Can you send a small piece of code that shows how you are writing. I am not
sure,but it seems too many values are copied to memory. The way around that
is references and pointers. This is C++?

Jeff

 

[mlimber]

Hi,

We are having a resource issue with our legacy codebase that involves
use of semaphores (in summary we use custom containers in an abstract
base class. Each uses 2 semaphores which causes lots of handles to be
consumed on windoze). when the application is under heavy load, we have
a lot of these containers, and thus semaphores being instantiated.
Eventually Bill Gates bombs out when no more handles are available. God
bless his soul.


Looking at the code, we see that the containers are instantiated in an
abstract base class. The obvious thing to do in this case is to move
the containers down into the non-abstract classes so we reduce the
number of times a container is instantiated (not all derived classes
need the containers and thus the semaphores) and so we'll save on the
number of semaphores consumed by the OS.

I'd like to know if there's a known c++ design approach that can be
adopted in this case. Is there any technique or strategy that is known
and can be generally applied in this kind of scenario. Its the design
rather than the detail (obviously, as I've given no detail ) that
interests me in this case.


Hope I've posted enough info. If not I'll add as needed.

have a nice day.

grahamO

Off the top of my head within the level of detail you've given, I'd say
you might create a second ABC that has the shared data, and have those
classes that need it inherit from the second ABC and those that don't
from the first. Something like:

class Base
{
public:
virtual void Foo() = 0; // interface
};

class BaseWithSharedData : public Base
{
public:
// ... doesn't implement Foo()
private:
Semaphore sem_;
std::vector<int> data_;
};

class DerivedWithoutData : public Base
{
public:
virtual void Foo() { /*...*/ }
};

class DerivedWithData : public BaseWithSharedData
{
public:
virtual void Foo() { /*...*/ }
};

Cheers! --M