Announcement

Collapse
No announcement yet.

Basic "Threading 101"

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Basic "Threading 101"

    As not to "Hijack" a question brought about from Kevin (last names held to protect the "Guilty" (or were they innocent?) ) I thought I would open my similar question (if not the same question)

    Many EXCELLENT points were brought up at http://www.powerbasic.com/support/pb...429#post305429

    Just a rough background to my limited thought of Threading
    1. Threads are great up to their point of "Diminishing Returns" of execution and speeding up your apps
    2. Globals are a "No-No" because of context switching and synchronization and such
    3. Welllllll hopefully this question will satisfy understanding the idiosyncrasy


    For my example of "A base Question" I will use the idea of enumerating all drives on a system. (Theoretically a possible 26 letters A-Z, and hence 26 threads, which is MORE than I have ever used, and should be WELL BELOW that point of "Diminishing Returns", but nice example)

    Ok, now I have my list of drives, (could be 3 could be 26), so I decide to thread to get info of each one to speed things up for the following reasons
    1. A:\ has no floppy, but default times out 3 seconds before telling me there is no floppy
    2. Z:\ Has a CD or DVD that spends time spinning up and spinning down before telling me its info
    3. Typical response....1 and 2 take MUCH longer than "Just give me the facts Mammm" and would save time if they could be found out during any "Down Time" I have
    4. Down Time to my understanding is "Managed by Windows OS" and could theoretically never occure (defeating my thread attempt)


    So that said...I create a UDT
    Code:
    TYPE MYTYPE
         DriveName as ASCIIZ * %MAX_PATH
         DriveInfo as WHATEVER
    END TYPE
    so each of my local threads, I create a variable as MYTYPE
    Question....Is the variable local to thread?, Can another thread corrupt the data?, Is my local really a global pointed at the same data??? and hence could be seen in the midst of changing???

    Since I am getting long in my question of questions I will keep it short, but also hazzard to guess that misuse of sleep, and misuse of tight loops will also change outcomes, and become more of a "Depends on your purpose" on what the answers are????
    Engineer's Motto: If it aint broke take it apart and fix it

    "If at 1st you don't succeed... call it version 1.0"

    "Half of Programming is coding"....."The other 90% is DEBUGGING"

    "Document my code????" .... "WHYYY??? do you think they call it CODE? "

  • #2
    It' does not 'depend on' anything.

    First thing, though...."LOCAL" is compile-time concept; a thread of execution is a run-time concept.

    That said, in the compiler's implementation, a LOCAL variable is unique to each entry to the procedure in which it is defined.

    If that procedure is a THREAD FUNCTION which is entered as a result of a THREAD CREATE statement, then each thread of execution will have a unique copy of that variable.

    If that procedure is a window or dialog procedure, then each notification message sent to that procedure is a unique entry, meaning the subject variable is unique to that particular message-processing code. This is what allows one window procedure to service many windows accurately, or what allows you to "send a message to yourself" whilst processing another message and have unique 'working' variables for each set of message-processing code in that procedure.


    MCM
    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]
    http://www.talsystems.com

    Comment

    Working...
    X