Thank you so much! That was quite a thorough explanation. I understood now
what you were trying to imply.
So, I'm going to do some research on how to make my code bulletproof. In
the mean time, can you suggest something on how to make this happen? .
I'll get back to you, once I've figured out this thing.
Thank you again,
Balraj.
On Thu, Jul 5, 2018 at 11:37 AM Balraj Singh <balraj.si...@zemosolabs.com>
wrote:
> Thank you so much! That was quite a thorough explanation. I understood now
> what you were trying to imply.
> So, I'm going to do some research on how to make my code bulletproof. In
> the mean time, can you suggest something on how to make this happen? .
> I'll get back to you, once I've figured out this thing.
>
> Thank you again,
> Balraj.
>
> On Wed, Jul 4, 2018 at 6:48 PM Dennis Buteyn <dennis.but...@xorcom.com>
> wrote:
>
>> Volatile only hints the compiler not to perform read optimizations, to
>> assume that the value is changed by some external process. This keyword was
>> designed for use in hardware drivers where memory-mapped devices would
>> alter values in-memory of which the compiler was not aware of. The volatile
>> keyword however later found a place in multi-processor systems as well
>> where memory is shared between execution units. The important thing to
>> understand however is that it only disabled read operations. It does not
>> provide any safety in regards to concurrent writes. This is what both me
>> and Richard were trying to explain to you.
>>
>> When two concurrent updates are performed on the same variable (making it
>> volatile does not matter) the final value will be that of whichever update
>> came last. Since no control mechanism is in place to ensure proper
>> ordering, this is no different than throwing dice.
>>
>> To ensure proper ordering of writes and to prevent modification by other
>> execution units you must use locks, of which you have none.
>>
>> The reasons why you may be getting somewhat sane output is because:
>>
>> 1. The system you are testing on is not a true SMP system.
>> 2. Process affinity restrictions apply, forcing your application to
>> run exclusively on a single execution unit.
>> 3. Your test calls are not actually concurrent.
>> 4. Your test calls are too slow.
>> 5. One of the many locks that Asterisk uses to prevent corruption of
>> its internal data structures is making your changes work.
>> 6. Luck.
>>
>> I understand you are getting "a" unique ID, what you fail to understand
>> is that it will not be the one you are looking for.
>>
>> Compile the following code on gcc with default options and watch it crash
>> instantly despite looking "correct", you will understand what we are trying
>> to tell you.
>>
>> #include <pthread.h>
>> #include <stdio.h>
>>
>> static volatile char * shared_var = NULL;
>>
>> void * threadfunc(void * ptr) {
>> for (;;) {
>> shared_var = "mystring";
>> char c = *shared_var;
>> shared_var = NULL;
>> }
>> return NULL;
>> }
>>
>> int main() {
>> pthread_t t1, t2;
>> pthread_create(&t1, NULL, threadfunc, NULL);
>> pthread_create(&t2, NULL, threadfunc, NULL); // comment this line to
>> make it "work".
>> pthread_join(t1, NULL);
>> pthread_join(t2, NULL);
>> }
>>
>> Dennis Buteyn
>> Xorcom Ltd
>>
>> On 07/04/2018 03:40 PM, Balraj Singh wrote:
>>
>> I know the working of static variables in Multi-threaded environment, but
>> I never used static variables ( please check the code sent in one of my
>> previous reply ) to save the unique-id. I'm using volatile keyword which is
>> completely different from static variable ( one of the storage classes in c
>> ), and the usage of volatile keyword here is to tell the compiler to not
>> perform optimisation ( while compilation ) on this variable. This is useful
>> in multi-threaded environment, as in global variable should be declared
>> volatile[1] in this type of environment for shared global variables.
>>
>> Regarding the second comment about unique-id being whatever at some point
>> of time : let me clear this thing, I already stated in my last reply that
>> I'm getting unique-id ( belonging to a call ) in logs correctly even in
>> concurrent calls ( tested with more than 1 call ).
>>
>> Please correct me if I'm wrong here.
>> @Richard Mudgett : Please validate the changes I did.
>> [1]
>> <https://docs.google.com/presentation/d/11LC-_e1EGL3X-n7gU_Z2uSNvPX41t6LVngO9AxBi4wo/edit?usp=sharing>
>>
>> Thank you all.
>>
>>
>>
>>
>>
>
> --
> *Thanks, *
> *Balraj.*
>
--
*Thanks, *
*Balraj.*
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
