Printable View
Hello,
Just a quick one: I have code that runs multiple threads and does a lot of thread-safe exchanges (in Windows, at the moment). But if the code is running on a system that cannot run threads independently (single core, no hyperthreading), is it worth detecting this condition and including a separate path that exploits this fact?
I don't know if using thread-safe exchange mechanisms (InterlockedExchangePointer() et. al) has a cost that could be optimised out, is all.
O_o
I read the title as "Is it worth detecting currency?" and was prepared to say "If you confuse a dollar $ (USD) for a peso $ (ARS) you'll be sued into oblivion so you are better off letting the user tell you the currency.". Yes, I was disappointed enough that I noted it for sake.
Now then, if you are using a compiler that transforms API (like `InterlockedExchangePointer') into native processor instructions you should be fine without considering the cost of the operation because the processor will know what it is capable of doing; if you are using a compiler that calls the actual API, from a shared library or something, I can't imagine the cost being more that any other API call.
So, I'd have to question such a simple notion of "exploiting the facts". If, for example, you currently use a simple algorithm with blocking IO but can use an alternative implantation that uses asynchronous IO doing work while waiting you'll probably find some benefit to working with the knowledge of the environment.
Obviously the answer depends on what the threaded version takes advantage of versus what the single version may use to its advantage.
Soma