If there is one master resource that each thread must acquire, then why are
you threading? Since your program is suffering starvation based on the
serialized access on the semaphore, you are losing the benefits of using
threads. I would recommend abandoning threads or using only one so you can
spawn off a thread to do a unit of work and return.

If you must be mult-threaded, then you will need a controlling semaphore per
thread so that the parent can act as round robin controller on the central
resource, telling each thread when it can take its turn.

Good Luck!
Chris

----------------------------------------------------
Chris Weiss, Blueoak Database Engineering, LLC
http://www.blueoakdb.com
PH: 517-381-9305
CELL: 517-974-5634
eFAX: 801-340-0740



-----Original Message-----
From: r [mailto:oracledba-ezmlmshield-x12440668.[Email address protected]
Sent: Monday, September 13, 2004 1:09 AM
To: LazyDBA Discussion
Subject: Optimising pro*c code in mulithreaded apps


Hi,

I've a pro*c program which uses threads. Many a times, a thread exits due
to its inability to obtain locks over a period of time.
Here is the sample of what i've written:-

Any ideas or suggestions on optimising a multithreaded pro*c program?

for(::)
{
..........
--- my program code is here ----

It recieves packets from a client and stores them in the database

Hence I need to obtain lock.
.............
for(i=0;;i++)
{
if(i>gMaxLockAtmpts)
{
logMsg("Cannot get dbmutex lock !!! Exiting thread...");
brk=1;
break;
}
if( mutex_trylock( &dbmutex[idx] ) == 0 ) break;
sched_yield();
}
if( brk ) {
sleep(3); /* invoking thread alone sleeps */
break;
}



}

close(socket)
pthread_exit((void *)0);

}

This e-Mail may contain proprietary and confidential information and is sent
for the intended recipient(s) only.
If by an addressing or transmission error this mail has been misdirected to
you, you are requested to delete this mail immediately.
You are also hereby notified that any use, any form of reproduction,
dissemination, copying, disclosure, modification,
distribution and/or publication of this e-mail message, contents or its
attachment other than by its intended recipient/s is strictly prohibited.

Visit Us at http://www.polaris.co.in


--------
website: http://www.LazyDBA.com
Please don't reply to RTFM questions
Oracle documentation is here: http://tahiti.oracle.com
To unsubscribe: see http://www.lazydba.com/unsubscribe.html
To subscribe: see http://www.lazydba.com
By using this list you agree to these
terms:http://www.lazydba.com/legal.html


Oracle LazyDBA home page