[ale] Linuxthreads question

[Christopher Fowler]

On Mon, Jun 23, 2003 at 10:13:53PM -0400, John Mills wrote:
> ALErs -
> 
> Not quite: I don't want to implement any new type of thread, i

You can't anyway.  clone() is the only road that gives you 
a thread.  pthreads in Linux will use that system call. 
Vfork is one way but I doubt it is used by pthreads.

> but just to
> make sure I use the 'linuxthreads' version in which each thread gets a
> different PID and won't block the others, but in which the threads can all
> share their parent's data segment where I will put my buffers. I
> specifically expect that I can avoid any locking, collision, or 'deadly
> embrace' problems by using multiple rolling buffers. 

If you use mutliple buffers, you may encounter performance issues
if you transfer from one to the other.  In other words, if you have
a buffer that the writer writes into then when he is done you transfer
it to a read buffer, your performance may go down the drain.  I faced
a simlar issue using strdup() in a parser.  

> If semaphores are
> used 'under the covers', I don't want to know about it.

Use mutexes and you'll be fine.
Just use them "right".  When you get into a so called critical section,
lock the mutex.  Below is an example:

 doSomeStuf();

/*
 * Critical Section
 */
 lockMutex(true);

 data->counter++;

 /*
  * End critical section
  */
 lockMutex(false);


Even though in the example we only incremented an integer in
shared memory, we locked the mutex so that a reader will
wait until it is available.  In the reader you'll do
this:

 doSomeStuf();

 /*
  * Critical Section
  */
 lockMutex(true);

 printf("Data Counter = %d\n" , data->counter):

 /*
  * End critical section
  */
 lockMutex(false);

It really is up to you as to what data is valuable and what is
not.  In your program, you may think you got everything timed
right but you'll fine that may not be the case all the time.  Many things
could through your timing out of whack and the only true way to
guarantee stable data is to use a good locking system for the shared
data.  In some of my stuff, I only lock when writers write and could
care less abot readers.  The data is informational only and the
writers are real important to keep going.  In other instances, I
lock both the readers and the writes but I make sure like in the 
above example that I keep my locks tight and not leave them 
locked for any lenght of time.  You do not want to lock then
go into a loop for 5 minutes.  If you need to enter a loop for
5 minutes, only lock when you access the data that is being shared.

> 
> The "thread" of my question was, how should I link to be sure I _do_ use 
> 'linuxthreads' and get per-thread PIDs.

I think on Linux it is libc '-lc'.  But, you'll need to make sure
you use the 'man 3thr' interface.  I wrote a program native to Linux
and needed to port to *BSD.  I should have use PThreads but I used clone
directly. Just make sure you do not use clone() in your code and you'll have
to use the 3thr API to do threading.  

> 
> Thanks for further comments.

There is one other solution that will avoid threads all together.  You
may want to just use fork() and each process has its own data segment.
What you need to do there is place your buffers in shared memory then
anyone (even debug programs) can access that data.  In those cases,
you can then use locking make sure the data is reliable. I use this
method much more than I use threads to share data.  I create an API
that any program can use to access the data and that includes locking
code and maping code.  It is fairly simple to do.  I have an embedded
device and *all* config info is up in memory.  Even user password
data that is usually stored in /etc/passwd.  For that case, I just replaced
libc getpwXXX() with my own implementation that would grab the data.  I also
have a piece of shared memory that stores system management info.  I then
created an API that even our snmp agent uses to grab data from that segment
as well as config.  In those case, it is awesome to use IPC to do
your shared data. 


> 
>  John Mills
>  john.m.mills at alum.mit.edu
> 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale
_______________________________________________
Ale mailing list
Ale at ale.org
http://www.ale.org/mailman/listinfo/ale