A question about OMP3.0 spec

General OpenMP discussion

A question about OMP3.0 spec

Postby Guest » Fri Jun 13, 2008 12:25 am

hi, in the new spec 3.0, there are two examples about flush directives, i.e. A.2.2 and A.2.3 , and the spec think it is not right.
I think that the two examples are right OMP program, and find many persons ask why it is wrong? But no one can tell me?
So can anyone give some further exaplaination about the wrong cases?
Guest
 

Re: A question about OMP3.0 spec

Postby ejd » Fri Jun 13, 2008 7:11 am

I am sorry that I didn't try and answer your question yesterday when you posted it in the other forum. I have really not been watching the other forum or answering questions in it. I was hoping one of the experts on the memory model would answer it. However, since you have asked the question here in this forum, I will attempt to answer it. There was a considerable amount of debate about these two examples during the OpenMP V3.0 spec work and they were suppose to be documented better. Unfortunately it slipped through the cracks in trying to get the spec out.

From what I saw of the debate, it breaks into two sides - the user side and the theoretical side. Taking example A.2.2c, from the user's perspective, no one understood why the print on line 35 wouldn't produce the correct result. The explanation of the problem goes back to the OpenMP memory model and what happens when you have a race. The OpenMP memory model says that whenever you have a race, such as in example A.2.2's use of "flag" for synchronization, the values returned by the reads involved in the race are undefined. That means that even though the thread executing the while loop on line 30 has seen a value of flag > 1, causing it to exit the loop, the values of both flag and data are undefined according to the memory model. After the subsequent flush on line 36, I would expect that both values (flag and data) would be correct. However, I see the comment (lines 37-38) says that the value of flag is still undefined.

In example A.2.3, the debate is about how atomic and flush interact. atomic guarantees that the value is written back, but the question is when it is written back and when is it seen by the code executing a flush. I am not going to say more than this right now, since I couldn't really fully explain the first example. I will send a note to the experts and see if I can get them to explain it.

From a practical side, I don't believe anyone has ever seen the problems that the memory model says could happen. The memory model may be more strict than it needs to be. However, that debate is continuing and you will see more changes in this area in the future as we continue to try and refine it. The overall feeling though, is that the use of flush is extremely hard to get correct and that we need to do a better job at providing the users with something to allow synchronization to be done more easily.
ejd
 
Posts: 1025
Joined: Wed Jan 16, 2008 7:21 am

Re: A question about OMP3.0 spec

Postby huizhanyi » Mon Jun 16, 2008 12:40 am

Thanks for your reply!

"The OpenMP memory model says that whenever you have a race, such as in example A.2.2's use of "flag" for synchronization, the values returned by the reads involved in the race are undefined. "
Can you give more details about what race has happened when we use "flag" for synchronization in this example?

"I will send a note to the experts and see if I can get them to explain it."
Thank you and wish your explanation.

"The overall feeling though, is that the use of flush is extremely hard to get correct and that we need to do a better job at providing the users with something to allow synchronization to be done more easily."
The method in the examples were often used for synchronization in the past, and so some persons, maybe experts in OMP, is surprised when the examples are deemed wrong.
huizhanyi
 
Posts: 4
Joined: Wed Jun 11, 2008 8:51 pm

Re: A question about OMP3.0 spec

Postby ejd » Mon Jun 16, 2008 5:43 am

huizhanyi wrote:"The OpenMP memory model says that whenever you have a race, such as in example A.2.2's use of "flag" for synchronization, the values returned by the reads involved in the race are undefined. "
Can you give more details about what race has happened when we use "flag" for synchronization in this example?

In example A.2.2c, the race is between the write of "flag" (and flush of the value) on on lines 21-24 and the reading of "flag" on lines 30-33.

"I will send a note to the experts and see if I can get them to explain it."
Thank you and wish your explanation.

The memory model experts are working on a response now. Hopefully it will be posted shortly.

"The overall feeling though, is that the use of flush is extremely hard to get correct and that we need to do a better job at providing the users with something to allow synchronization to be done more easily."
The method in the examples were often used for synchronization in the past, and so some persons, maybe experts in OMP, is surprised when the examples are deemed wrong.

The OpenMP memory model experts weren't surprised - they were the ones that put the examples in. However, there has been a good deal of discussion on the use of flush and the memory model. Some people on the committee think that flush should be removed completely. Others think that it has value. So look for more changes to it (hopefully for the better) in the future.
ejd
 
Posts: 1025
Joined: Wed Jan 16, 2008 7:21 am

Re: A question about OMP3.0 spec

Postby ejd » Fri Jun 20, 2008 4:13 pm

If you look in the other forum (OpenMP 3.0 API Specifications) where you first posted this query, one of the OpenMP Memory Model experts has responded.
ejd
 
Posts: 1025
Joined: Wed Jan 16, 2008 7:21 am

Re: A question about OMP3.0 spec

Postby Guest » Wed Aug 13, 2008 11:27 pm

I think I need furthrer explaination about the problem.
Guest
 


Return to Using OpenMP

Who is online

Users browsing this forum: Google [Bot], Yahoo [Bot] and 6 guests