[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.programming.threads

issues in using pthreads in a library

vghiware

8/8/2004 11:31:00 AM

Hi !

I am working on a library, which has a synchronize method
to ensure all programs using this library use the correct resource
file.

However this function is called only when the process makes an attempt
to get some data ( why ? because someone designed it this way )

--snip--
myClass::GetData()
{
Synchronize()

/* get the data from the latest file
* return
*/
}
--snap--

If the process using this library doesn't call the GetData Method
frequently
enough, it would cause the process to have an handle to stale resource
for too long :( and unnecessarily waste the disk space.

Somehow if the Synchronize function was called frequently by the
programs , my problems are gone, however none of the programs
want changes in their code nor they want to recompile and
link to the new library( once i have made the changes )

I plan to create a thread in the constructor of my library class , and
thus start a thread for each process which keeps on calling the
Synchronize() ,say every 5 sec.( am i implimenting the singleton
pattern ?? )

--snip--
myClass::myClass{
/* do initialization */
pthread_create(&thread,NULL,callThread,NULL)
}
void *callThread(void)
{
if(pthread_mutex_trylock(&mymutex)){
// error
// A thread is already running.
pthread_exit(NULL);
}else{
// i have the lock now, keep calling the synchronize method.
myClass temp;
while(1)
{
sleep(5);
temp.Syncronize();
}
}// else ends

}//callThread ends

--snap--

I have kept the mutex in global scope and initialized it.


1)Is constructor ok ??

2)I do not handle any signals in the thread (or any function of the
library ),so the thread should not cause any harm to the signal
handling mechanism of the process? right?

3)But im not sure what would happen if the any of the programs using
this lib do a fork in the main() and not do execvp ( or any related
functions )

4)Also what if the programs using the library , do not link to
libpthread.sl?
will it suffice if i link my library to libpthread.sl ??

The prototype works fine for me,till now.

im working on HP-UX 11.0

Do you see any issue with this kind of implementation ?

Thanks in advance.

vaibhav
3 Answers

Joe Seigh

8/8/2004 11:55:00 AM

0



Vaibhav wrote:
>
> Hi !
>
> I am working on a library, which has a synchronize method
> to ensure all programs using this library use the correct resource
> file.
>
(snip)
>
> The prototype works fine for me,till now.
>
> im working on HP-UX 11.0
>
> Do you see any issue with this kind of implementation ?
>
> Thanks in advance.
>

Ask Rajesh. He's already working on the problem. You need to
work on your intra-group coordination a little more. Also,
articulating what you are actually trying to do would help.
I suspect that part of the problem is that you don't even know
what you are trying to do.

Joe Seigh

Joe Seigh

8/8/2004 2:41:00 PM

0



Vaibhav wrote:
>
> I plan to create a thread in the constructor of my library class , and
> thus start a thread for each process which keeps on calling the
> Synchronize() ,say every 5 sec.( am i implimenting the singleton
> pattern ?? )

It would help if you recognised you are doing a readers/writers pattern.
Singletons have nothing to do with that unless you think they're the
immutable objects in a COW (Copy On Write) solution to the readers/writers
problem. Singletons tend to have a permanent lifespan and only get deallocated
in the main thread during shutdown when being shared is not an issue.

There is range of solutions to the readers/writers problem with various
benefits and trade offs. It depends on what you want. I don't know what
you want. Do you know what you want?

....
> 2)I do not handle any signals in the thread (or any function of the
> library ),so the thread should not cause any harm to the signal
> handling mechanism of the process? right?
>

Signals can be handled on any thread that is enabled for those signals.
Processes do not handle signals. As there isn't really any way that you
have signal handlers and threads interact with each other, it shouldn't
matter which thread handles the signal unless you are doing something
that is async unsafe, in which case you will probably have problems anyway.
So you shouldn't have any problems with a thread that probably shouldn't
be running anyway.

Joe Seigh

Thomas Rydzynski

8/9/2004 5:36:00 PM

0

Vaibhav wrote:
> --snip--
> myClass::myClass{
> /* do initialization */
> pthread_create(&thread,NULL,callThread,NULL)
> }
> void *callThread(void)
> {
> if(pthread_mutex_trylock(&mymutex)){
> // error
> // A thread is already running.
> pthread_exit(NULL);
> }else{
> // i have the lock now, keep calling the synchronize method.
> myClass temp;
> while(1)
> {
> sleep(5);
> temp.Syncronize();
> }
> }// else ends
>
> }//callThread ends
>
> --snap--

There is a function called pthread_once that will work better than that
trick with mymutex I think.

Sorry, but I can't give valuable answers to your questions.

Personally, I have some concern about using threads with program that
was not compiled with mutlithreading support, at least under Linux.
Under Linux it is needed to recompile such program to make it work
correctly.

Regards,
--
} Tomek Rydzynski {.} Mówie NIE patentom na oprogramowanie. {
} qsorix poczta onet pl {?} {
} Moloch Developer {!} http://www.ff... {