Connection Pool -- Locking, Concurrent Access

Reply

Join Date: Jul 2008
Posts: 15
Reputation: vadan is an unknown quantity at this point 
Solved Threads: 0
vadan vadan is offline Offline
Newbie Poster

Connection Pool -- Locking, Concurrent Access

 
0
  #1
Aug 26th, 2008
Sorry for all my previous posts

let me explain the exact problem

There is a singleton object in the shared memory. It conatins a pool of connection objects to a server. (more likely an array of connection objects).
I want to go through the array and find which connection object is free to access.

Then that particular object is locked, used for connection and then unlocked.
The following is the singleton object which encapsulates the connection pool array.

class single
{
private:
~single();
single();
connectionObj[5];
public:
connectionObj & GetConnectionObj() ;
void Lock();
void UnLock();
}

There are at least 8 processes that are simultaneously accessing the singleton object.

I want a synchronization between all these process and want to implement GetconnectionObj() function. How to implement it and where the locks must be used.

Should the locks be while accessing singleton object or while acessing the connection object, or both

please explain me with the help of code

Thanks in advance

Regards
VADAN
Reply With Quote Quick reply to this message  
Join Date: Aug 2005
Posts: 15,152
Reputation: Ancient Dragon has a reputation beyond repute Ancient Dragon has a reputation beyond repute Ancient Dragon has a reputation beyond repute Ancient Dragon has a reputation beyond repute Ancient Dragon has a reputation beyond repute Ancient Dragon has a reputation beyond repute Ancient Dragon has a reputation beyond repute Ancient Dragon has a reputation beyond repute Ancient Dragon has a reputation beyond repute Ancient Dragon has a reputation beyond repute Ancient Dragon has a reputation beyond repute 
Solved Threads: 1437
Team Colleague
Featured Poster
Ancient Dragon's Avatar
Ancient Dragon Ancient Dragon is online now Online
Most Valuable Poster

Re: Connection Pool -- Locking, Concurrent Access

 
0
  #2
Aug 26th, 2008
*nix shared memory with semiphores

Despite my previous statement, I think you only need one semiphore to synchronize access to that array of objects. Semiphones for each array element isn't necessary because you are doing your own reference counting for each connection object.

For any given process, this is what I would do to gain control of a connection object. Similar method to free a connection object, except of course you decrement the reference count.
  1. forever loop
  2. Get semiphone (wait indefinitely until it is available)
  3. Is a free connection object available
  4. Yes, increment connection object, release semiphone, and exit loop
  5. None available, release semiphone, sleep a few clock ticks to allow context switch,
  6. then return to top of forever loop
  7. end of forever loop

Under MS-Windows you wouldn't need that shared memory array, just create 5 semiphones, then call WaitForMultipleObjects( ... ) to gain access to the first available semiphone. I don't know if anything similar is available on *nix or not.
Last edited by Ancient Dragon; Aug 26th, 2008 at 3:01 am.
Don't PM me with questions -- you might get a nasty PM in response. If you have a question then post it in one of the forums.
Reply With Quote Quick reply to this message  
Join Date: Jul 2008
Posts: 2,001
Reputation: ArkM has much to be proud of ArkM has much to be proud of ArkM has much to be proud of ArkM has much to be proud of ArkM has much to be proud of ArkM has much to be proud of ArkM has much to be proud of ArkM has much to be proud of ArkM has much to be proud of 
Solved Threads: 343
ArkM's Avatar
ArkM ArkM is offline Offline
Postaholic

Re: Connection Pool -- Locking, Concurrent Access

 
0
  #3
Aug 26th, 2008
You need a single private (not public) lock in your connections manager to implement critical sections in getConnection() and freeConnection() member functions.
Pseudocode for non-locking solution (when we return no_available_conn value to requestor):
  1. Result ConnnectionManager::getConnection()
  2. {
  3. begin critical section (lock semaphore/mutex)
  4. result = no_available_conn
  5. search connections array for free slot
  6. if free slot found then
  7. mark it as busy
  8. result = selected_conn_handler
  9. end critical section (unlock semaphore/mutex)
  10. return result
  11. }
  12.  
  13. void ConnectionManager::freeConnection(conn_handler)
  14. {
  15. begin critical section (lock semaphore/mutex)
  16. find busy slot by conn_handler
  17. if found then
  18. mark it as free
  19. end critical section (unlock semaphore/mutex)
  20. }
Another (classic) solution: use P/V operations with the single private (not public) semaphore:
  1. ConnectionManager::ConnectionManager()
  2. {
  3. Prepare conn[N] array
  4. Initialize sem(N)
  5. }
  6. Result ConnectionManager::getConnection()
  7. {
  8. sem.P(); // lock process if no available connections
  9. find free slot and return its handler
  10. }
  11. void ConnectionManager::freeConnection(conn_handler)
  12. {
  13. find slot by conn_handler
  14. mark it as free
  15. sem.V(); // signal that free conn is available
  16. }
For P/V operations see, for example:
http://en.wikipedia.org/wiki/Semaphore_(programming)

No standard C++ types and functions for semaphores, mutexes and critical sections.
There are some portable libraries implementing this stuff, for example:
http://www.boost.org/

Avoid public locking functions. Incapsulate these delicate operations as deep as possible.
Reply With Quote Quick reply to this message  
Reply

This thread is more than three months old.
Perhaps start a new thread instead?
Message:



Other Threads in the C++ Forum
Thread Tools Search this Thread



About Us | Contact Us | Advertise | DaniWeb | Acceptable Use Policy | RSS Feed

©2003 - 2009 DaniWeb® LLC