Use the volatile modifier to indicate that a variable can be changed by a background routine, an interrupt routine, or an I/O port. Who could you make the conclusion that pNodes is considered as volatile by the compiler? Are there any standard approaches to check whether a variable in C/C++ is considered as volatile (or non-volatile) by the compiler? The member pNodes is considered as volatile by the compiler Am I correct? Is it in C/C++ standard that a pointer variable will be initialized with non-NULL value (or NULL value) by default (I mean if we do not assign a value explicitly when declare a pointer variable)?Ģ. I think you mean Next pointer is initialized to non-NULL value by default. In fact my trace is simplified, since i considered that each C++ statement is executed atomically, and that the member pNodes is considered as volatile by the compiler.From your reply, I think when you are mentioning crash, you are based on two conditions, It is just a 'possible trace', and many other buggy possibilities may occur, with unpredictable results. In fact my trace is simplified, since i considered that each C++ statement is executed atomically, and that the member pNodes is considered as volatile by the compiler. Moreover, if the stack already contained some nodes, and we need three or more pop operations, the third pop operation will probably crash! Now, calling Stack::length will probably crash the process, if pNodes->Next->Next is non-NULL, but still an invalid pointer. The first node of the list (Node2) points to a second node (Node1), which is not initialized (so pNodes->Next->Next is invalid). that is Node1!Now our list is in an inconsistent state: Thread2 pNodes->Next=pOldNodes // now Node2 points to pOldNodes of thread2.
Thread2 pNodes->Value=x // set the integer value of Node2 to the value of x of thread1 Thread1 pNodes->Next=pOldNodes // Node2 now points to Node0 Thread1 pNodes->Value=x // set the integer value of the Node2 to the value of x of thread1 Thread2 pNodes=new Node // set pNodes to another new Node (we name it Node2) Thread2 Node *pOldNodes=pNodes // pOldNodes in thread2 now points to Node1 Thread1 pNodes=new Node // set pNodes to a new Node (we name it Node1) Could you please help?Ĭode: thread1 Node *pOldNodes=pNodes // pOldNodes in thread1 points to the first node of the old list. What do you mean " it would be dangerous though to modify someCondition while handling a broadcast because multiple threads have been woken up"? I have not seen very much difference when using broadcast with more than one producer (or consumer) threads. I simply want to wake up only one producer (or consumer) when we have appropriate consitions. In my requirements, there will be multiple producers and multiple consumers. It makes a difference if there are multiple producer/consumer threads or just one producer and one consumer and you are using condition variables simply to synchronise the producer with the consumer.Your reply is very helpful. Note it would be dangerous though to modify someCondition while handling a broadcast because multiple threads have been woken up.Ī lot depends on your design as to what someCondition will be next time you loop. If it receives a broadcast it may do some other processing and then will continue to wait if the condition is still false after the broadcast. The loop as written will wait until the condition is true then handle it.
0 kommentar(er)
