🚀 go-pugleaf

Keith R. Bennett (kbennett@access.digex.net) wrote:
: 
: 
: I have a question about thread programming.  Is there any way to make
: a given variable specific to an instance of a thread?
: 
: The best I can think of so far is to use either local variables, or
: variables allocated from the heap.  There is a large number of
: these variables that will be thread-specific, so I was thinking
: of putting them in structures and creating a new instance of each
: structure for each thread.
: 
: The C++ programmers guide mentions that there is a separate copy of
: errno for each thread.  Can I do that with my own variables?
: 

Yes, there is an errno for each thread. At least when you use
_begin_thread. I am not sure whether a new errno is created when you
directly call DosCreateThread.

With _begin_thread you can pass a parameter list to the thread. This
parameter list (it may contain simple variables as well as arrays and
structures) could be used to have thread-specifics.
This way you can preload some or all of these variables, which you
cannot when the thread allocated memory from the heap for its specifics.

WARNING: Do not use local variables (allocated on the stack) of the
procedure that calls _begin_thread as parameters to the thread. When
leaving the procedure, all your locals will be gone and the thread will
be 'ghost-operating' on your stack.

Han

In article <28efue$478@access.digex.net> kbennett@access.digex.net (Keith R. Bennett) writes:
>
>I have a question about thread programming.  Is there any way to make
>a given variable specific to an instance of a thread?
>
>[...]

There is no way (that I know of) to make a *global* variable specific to
a thread.  However, since each thread has its own stack, any variables
allocated on the stack (as automatics or using _alloca()) will be thread-
specific.
-- 
Bob Dedrick                |   Internet: bob@dev.prodigy.com
Prodigy Services Company   |    PRODIGY: HFDD60A
445 Hamilton Avenue        |      Voice: +1 (914) 993-8855
White Plains, NY 10601 USA | Disclaimer: Not an official Prodigy spokesman

In <28ins7$fvv@tinman.dev.prodigy.com> bob@tinman.dev.prodigy.com (Bob Dedrick) writes:

>In article <28efue$478@access.digex.net> kbennett@access.digex.net (Keith R. Bennett) writes:
>>
>>I have a question about thread programming.  Is there any way to make
>>a given variable specific to an instance of a thread?
>>
>>[...]

>There is no way (that I know of) to make a *global* variable specific to
>a thread.  However, since each thread has its own stack, any variables
>allocated on the stack (as automatics or using _alloca()) will be thread-
>specific.

After having to deal with this kind of crap since version 1.(1 or 2, I can't
remember), I can say that after designing/implementing many different inter-
thread communication mechanisms, I find that the easiest to use is the
following:

1)  Define two user messages

    #define MYM_STARTTHREAD (WM_USER)
    #define MYM_ENDTHREAD (WM_USER+1)

2)  For every type of asynchronous action needed, allocation 1 bit out of
    a total of 32 for it and define a constant for it.  E.g.,

    #define ASYNC_OPEN 0x00000001L
    #define ASYNC_PRINT 0x00000002L

    For each window class, create a ULONG field in the instance data to
    hold the bits corresponding to the threads started by windows of this
    class.

3)  Also, for each action, define a structure containing all variables to
    be *sent* to the thread and all variables to be *returned* from the
    thread.  The first field *MUST* be a ULONG containing the size of the
    structure for the purposes of communicating to PM the amount of memory
    to thunk, should that be required in a system call.

    You might want to also create a common THREADINFO structure containing
    fields that all threads will have, to save you some typing.

4)  Whenever a window needs to perform some lengthy processing, it sends
    itself a MYM_STARTTHREAD with LONGFROMMP(mpParm1) specifying the type
    of thread required and PVOIDFROMMP(mpParm2) pointing to an *already
    initialized* thread structure (see step 3) to be passed to the thread.

    The message processing can first cast this pointer to PTHREADINFO
    (assuming you typedef'd one as recommended) to initialize the common
    fields (one that is needed is the window handle of the "owning" thread).
    It then switch's on the thread type in order to: malloc() a block to
    copy this thread-specific structure into, in case the pointer passed in
    pointed to an automatic variable, and also to determine the procedure for
    the thread.  Finally, it calls _beginthread to start the thread,
    specifying the pointer to the malloc()'d block as the parameter to the
    thread.

    The thread receives this pointer, does its stuff, sets the variables to
    be communicated back to the window in the structure and executes the
    following code (assuming the definitions at the beginning):

    VOID _Optlink mythread(PMYTHREADINFO pmtiInfo)
    {
        :
       WinPostMsg(pmtiInfo->hwndOwner,
                  MYM_ENDTHREAD,
                  MPFROMLONG(ASYNC_SOMETHING),
                  MPFROMP(pmtiInfo);
       DosEnterCritSec();
       pmtiInfo->bThreadDead=TRUE;
    }

    The owning window resets the bit in its ULONG to specify that the
    thread is no longer active and free()'s the memory (after executing
    the following loop to insure that the thread is dead)
   
    while (!pmtiInfo->bThreadDead) DosSleep(0);

    Of course, any return codes from the thread (via the structure) are
    checked, etc.

What are the advantages of this method?

1)  Look Ma, no global variables!

2)  The procedure of the owning window can intercept the WM_MOUSEMOVE and
    WM_CONTROLPOINTER messages and return the appropriate value to specify
    SPTR_WAIT should the ULONG ulAsync variable in its instance data be
    non-zero.  This provides excellent user-feedback.  Additionally, the
    WM_INITMENU can be intercepted and any menu items needed can be
    disabled depending on which threads are active.

Any questions can be directed to me either through the conference or email.

Cheers,
Q
-- 
Have you read this month's EDM/2?  It's available via anonymous FTP to
ftp.cdrom.com in the /pub/os2/2_x/program/newsltr directory.  New articles,
comments, suggestions, and Q&A questions are always welcome!  Send all to
os2man@panix.com .

In article <28efue$478@access.digex.net> kbennett@access.digex.net (Keith R. Bennett) writes:

>   I have a question about thread programming.  Is there any way to make
>   a given variable specific to an instance of a thread?
>
>   The best I can think of so far is to use either local variables, or
>   variables allocated from the heap.  There is a large number of
>   these variables that will be thread-specific, so I was thinking
>   of putting them in structures and creating a new instance of each
>   structure for each thread.
>
>   The C++ programmers guide mentions that there is a separate copy of
>   errno for each thread.  Can I do that with my own variables?

There is a feature supplied by C Set/2 library called _threadstore.
It gives the address of a (void *) which is private to each thread.
You can put a pointer to thread-local information into this pointer:

void mythread(void *threadparam)
{
    struct thread_info info;    /* Allocate thread-private info on
                                   this thread's stack */

    *_threadstore = &info;      /* Place that private info's
                                   address into _threadstore */

[...]

elsewhere(void)
{
    struct thread_info *info = *_threadstore;
-- 
Richard Krehbiel          rich@kastle.com or richk@grebyn.com
OS/2 will do for me until AmigaDOS for the 386 comes along...