Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re^6: Standard way to convert timezone in multithreaded script

by BrowserUk (Patriarch)
on Nov 24, 2009 at 19:58 UTC ( [id://809191]=note: print w/replies, xml ) Need Help??


in reply to Re^5: Standard way to convert timezone in multithreaded script
in thread Standard way to convert timezone in multithreaded script

Articulated lorries (semi trucks) are much bigger and slower than F1 or Indy cars. Diesel-electric freight trains even bigger and slower.

But, it doesn't mean that any time someone has a minor problem with their truck (the satnav in my truck sometimes looses the gps signal), or train (the horn on my loco sometimes sqeaks rather than bellows), that the appropriate response is: Trucks (trains) are big and slow; what you need is an F1 car!

To advise which of those two extremes, or where between them, is the most appropriate tool for the OPs problem, requires that you first have some information regarding that problem. And then the best advice will depend upon the problem being tackled.

It's all about giving an appropriate response to the question asked. For the OPs question, that was that his apparent expectation that changing the value of $ENV{TZ} would directly and immediately affect the behaviour of localtime, is misplaced.

Descending into a rant that he should not be using threads, when there is zero information in his OP of what or how he is using threads, is simply an inappropraite response. Doing so in the basis of your near total misunderstanding of the subject of your rant is ...


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^7: Standard way to convert timezone in multithreaded script
by zentara (Archbishop) on Nov 25, 2009 at 10:23 UTC
    ... yeah soory BrowserUk... i concede that you have every right to jump on my case for what i said.... sorry if i spewed some ignorance about the functioning of multi-core motherboards, but i don't have one

    ...i do wonder about the wisdom of allowing a process to launch threads into other cores, other than the one it's parent exists in.....

    i'm in that zen trap, where the external world becomes a reflection of the inner mind, and i use this as a guide to developing my artificial intelligence strategy.

    ..... and in my inner mind, i have distinct barriers between cores ( so to speak)...... my visual cortex dosn't allow the audio core processing to occur in the visual core... etc.... a separation for safety.... and in that train of thought, i require that i can reset a single core, without resetting the whole set of cores...... if my collision-detection system goes bonkers, i don't want it to affect my steering...etc. .... and i don't want to have to deal with worrying that maybe the collision-detection code somehow got it's malfunctioning code into my steering core

    .... but i guess for gamers, or pure dedicated number crunching, this cross-core core chaos would allow more speed.... but at a risk

    .... another point that seems troublesome, is that can you be sure that the thread spawned will go into another core?.... for instance.... to use tirwhan's 1-liner as an example..... he says as you spawn muliple threads, they automatically get assigned to other cores..... but what if one core is already heavily loaded?..... wouldn't the scheduler tend to drop more than one thread into one of the unloaded cores?....... or is there a way to specifically direct which core the code block goes into?..... otherwise 8 threads could end up like 1 in cpu0, 3 in cpu1 , and 4 in cpu2 because cpu5 thru 7 are already running a heavy load

    .... anyways..... it seems like all this multicore cross-core-exection stuff is aimed at gamers, and a security grade processor would automatically deny this behavior to confine all bad-acting apps and their spawn( whether it be forks or threads) to the originating core

    ....but maybe i'm just an old dog, whose is more worried that someone is going to steal my bone, than moving my bones around faster ...... fwiw... my spaceship controls have core separation :-)


    I'm not really a human, but I play one on earth.
    Old Perl Programmer Haiku
      but what if one core is already heavily loaded?

      The kernel decides where and when your code will be executed. This is regardless of whether it executes in a thread or a process, it's the OSes job to manage the running of user-space code (userspace can influence which core it'll run on by setting CPU affinity, but doing that is almost never a good idea, and anyway the important decision of "when" and "how long" it'll run is governed by the OS). So, if you're on a heavily loaded system, the OS may decide to execute new threads on the same CPU as the spawning process, or on a different one. It may move a thread/process to a different core or not. These decisions depend heavily on what exactly the thread in question and other processes are doing, what priority they're running under, whether they're IO-bound or CPU-bound, whether they're interactive or not etc. The mechanism by which the decision is reached is exactly the same(*), regardless whether you're talking about threads or processes. It is also exactly the same regardless whether you're on a single-core or multi-core machine, the results may be different, but the principles are the same.

      Just answering this to clear up a concrete question. I'll leave this thread now, sorry, but all this blather talk about "resetting cores" and "security grade processors" is making my brain hurt.

      (*) caveat here, it's been a while since I read up on the current Linux implementation, so there may be some difference in the kernels decision-making process, but I'm willing to bet aforementioned amount that this difference does not matter at all in the context of the current discussion.


      All dogma is stupid.
      another point that seems troublesome, is that can you be sure that the thread spawned will go into another core?.... for instance.... to use tirwhan's 1-liner as an example..... he says as you spawn multiple threads, they automatically get assigned to other cores..... but what if one core is already heavily loaded?..... wouldn't the scheduler tend to drop more than one thread into one of the unloaded cores?.

      You don't assign threads to cores, the scheduler does. Essentially, when you create a thread (at the C/machine-code level), you are simply adding a node (a struct) to a kernel-internal list, queue or tree. The kernel gets woken up by a hardware interrupt every few milliseconds and it decides if the current thread has had its time slice. If it has, it saves the contents of the CPU registers (into the node that was added when the thread was created), and picks another thread from those in the list (or queue or tree).

      The algorithm used to decide which thread is next varies from OS to OS; and kernel to kernel (and kernel version to kernel version). In an SMP (multi-core or multi-cpu) system, each cpu picks from the same list. So there is no determinism about which cpu will run any given thread, it is just down to which one pops out of the scheduling algorithm of choice.

      ...i do wonder about the wisdom of allowing a process to launch threads into other cores, other than the one it's parent exists in.....

      Don't concern yourself. Processes are not assigned to cores--threads are. A process consists of a (protected, in modern OSs--including *nix and MSWin :), virtual address space + one (or more), threads.

      Virtual address spaces (on Intel, but equivalently on other modern processors), are controlled by ring 0 entities called Global Descriptor Tables (GDTs). Threads are bound to one (or a few) GDTs, and have no ability to change those bindings. In other words, processes, and therefore, the thread(s) of those processes, are protected from each other, by hard-wired (hardware) protection mechanisms.

      Whilst it is possible (under MSWin, given sufficient privilege; and probably under *nix, but I don't know enough to say for sure), to "inject a thread into a different process", it does require privilege. If you habitually run as root (Administrator), this can render you vulnerable. The solution: Don't!

      For the pedants: Of course, this is a gross simplification and not truly representative of any given system. But the devil is in the detail. Namely, the "scheduling algorithm of choice".


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://809191]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others wandering the Monastery: (7)
As of 2024-03-28 10:35 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found