[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.programming.threads

posix threads and signal handlers on HP-UX

rajesh.rajguru

8/7/2004 7:49:00 AM

We have a library which is used by many applications.This library has
two cache files(always one will be active)
Now we want to implement the threads in our library such a that every
application (process) using this library ,will create its own thread
and will keep running in its thread context. In this thread context we
will try to map the active cache file
We are thinking for following type of pseudo-code

void *refresh(void *arg)
{
//static mutex declaration
// pthread_try_lock()
// if locking is successful , wait for some time and map the active
cache file
//else exit thread
}

main()
{
//create thread (refresh will be passed as parameter)

}

As many processes will try to create the their threads (as they access
the same library), do you think of any problems in such types of
implementation ?
Will there be any problems if main process gets signal ?

Thanks & Regards,
Rajesh
3 Answers

Joe Seigh

8/7/2004 3:28:00 PM

0



Rajesh Rajguru wrote:
>
> We have a library which is used by many applications.This library has
> two cache files(always one will be active)
> Now we want to implement the threads in our library such a that every
> application (process) using this library ,will create its own thread
> and will keep running in its thread context. In this thread context we
> will try to map the active cache file
> We are thinking for following type of pseudo-code
>
> void *refresh(void *arg)
> {
> //static mutex declaration
> // pthread_try_lock()
> // if locking is successful , wait for some time and map the active
> cache file
> //else exit thread
> }
>
> main()
> {
> //create thread (refresh will be passed as parameter)
>
> }
>
> As many processes will try to create the their threads (as they access
> the same library), do you think of any problems in such types of
> implementation ?
> Will there be any problems if main process gets signal ?
>

It's not at all clear what you are trying to do here. Why do you think
the libraries need a thread from each process? What are the threads
supposed to do that can't be done otherwise? You don't need a thread
to map a file, just a file descriptor and file descriptors are owned by
the process, not threads.

Signals? No problem as long as you handle the signal properly. What's
properly? I don't know. It all depends on what you haven't told us.

Joe Seigh

Dave Butenhof

8/9/2004 11:45:00 AM

0

Rajesh Rajguru wrote:

> We have a library which is used by many applications.This library has
> two cache files(always one will be active)
> Now we want to implement the threads in our library such a that every
> application (process) using this library ,will create its own thread
> and will keep running in its thread context. In this thread context we
> will try to map the active cache file
> We are thinking for following type of pseudo-code
>
> void *refresh(void *arg)
> {
> //static mutex declaration
> // pthread_try_lock()
> // if locking is successful , wait for some time and map the active
> cache file
> //else exit thread
> }
>
> main()
> {
> //create thread (refresh will be passed as parameter)
>
> }
>
> As many processes will try to create the their threads (as they access
> the same library), do you think of any problems in such types of
> implementation ?

"// static mutex declaration"? For one thing, if you've got ONE thread
running your refresh() routine in each process, you DO know, I hope, that
each will be calling pthread_mutex_trylock() on its own, private copy of
that static mutex?

Mutexes are not by default shared across processes -- even process running
from the same disk image of a shared library. Even when those processes may
be sharing access to the same read-only text pages. Static writable data,
like a mutex, will NOT normall be shared between processes.

If you really want to have threads in different processes using the same
mutex to access a shared memory region, you need to dynamically initialize
the mutex using pthread_mutex_init(), and with the PTHREAD_PROCESS_SHARED
value set for the pshared attribute.

However, I will also join Joe Seigh in asking precisely why you think you
need to have a dedicated background thread in each process using your
shared library?

More specifically, what are you actually trying to accomplish?

--
/--------------------[ David.Butenhof@hp.com ]--------------------| Hewlett-Packard Company Tru64 UNIX & VMS Thread Architect |
| My book: http://www.awl.com/cseng/titles/0-20... |
\----[ http://homepage.mac.com/dbutenhof/Threads/Th... ]---/

kamalp

8/10/2004 6:52:00 PM

0

rajesh.rajguru@wipro.com (Rajesh Rajguru) wrote in message news:<69d61a0b.0408062349.3b1730d7@posting.google.com>...
> We have a library which is used by many applications.This library has
> two cache files(always one will be active)
> Now we want to implement the threads in our library such a that every
> application (process) using this library ,will create its own thread
> and will keep running in its thread context. In this thread context we
> will try to map the active cache file
> We are thinking for following type of pseudo-code
>
> void *refresh(void *arg)
> {
> //static mutex declaration
> // pthread_try_lock()
> // if locking is successful , wait for some time and map the active
> cache file
> //else exit thread
> }
>
> main()
> {
> //create thread (refresh will be passed as parameter)
>
> }
>
> As many processes will try to create the their threads (as they access
> the same library), do you think of any problems in such types of
> implementation ?

I hope you are aware of the process-model on UNIX that encapsulates
thread instances. I mean, when a process creates a thread -it is
unique to that process, pretty much like malloc()ing inside a process.
When the code is in a library, each process linked with that library
has its own data segment on which the library malloc()'es, even though
the text segment is in the library (if it is a shared one -in case of
statically linked lib, the text segment is part of the
process/program). If you create a thread inside a library function,
that is as good as creating a thread inside one of the program's
functions -and it does not matter how many programs are linked to the
library or how many instances of such programs are in execution at the
same time.

> Will there be any problems if main process gets signal ?
>
You must mean main thread -which is the thread executing main().
When the signal is sent to the process, threads which have not set
their sigmask will receive the signal.

regards
-kamal

> Thanks & Regards,
> Rajesh