Update slide wording on USM blocking behavior

[EwanC]

This PR proposed changes to the "Using_USM" slides on the blocking behavior of USM malloc and free, and "Fast Track" identical slides.

Currently the slides say that malloc_device and free are blocking, however I feel that terminology could be misleading to beginners as with the queue parameter it implies the entry-points could be asynchronous, which they are not. I think it is more informative to say that the entry-points are synchronous which is terminology used in the other lessons

For sycl::free in particular I believe the following bullet points were incorrect for the following reasons:

• "This is a blocking operation.", we explicitly added a note in Fix description of sycl::free SYCL-Docs#758 saying it could be blocking or non-blocking.
• "The queue must be the same as was used to allocate the memory.", I don't see this wording anywhere in the spec and not sure if it would be enforceable given a USM allocation can be made using a malloc entry-point taking a device and context rather than a queue

[illuhad]

"This is a blocking operation.", we explicitly added a note in KhronosGroup/SYCL-Docs#758 saying it could be blocking or non-blocking.

That's true, however AFAIR "blocking" there refers to device work -- not to the host. free has always been "blocking" with respect to the host and the free operation: Once the function is returned, the free can be assumed to be complete (or at least, changes no longer observable). That said, I think your change does make this clearer.

"The queue must be the same as was used to allocate the memory.", I don't see this wording anywhere in the spec and not sure if it would be enforceable given a USM allocation can be made using a malloc entry-point taking a device and context rather than a queue

You're right. The correct statement would be that it "must use the same context that was used to allocate the memory". I could imagine that this was simplified for teaching reasons. If I recall, we kind of tried to avoid focusing too much on context, because nobody knows what exactly it is, and it's difficult to give beginners satisfying answers about it.

I'm not opposed to your change, but would perhaps suggest that we first survey the material for how/to which extent we introduce context in the materials before this lesson, unless you already have done so?

[EwanC]

I'm not opposed to your change, but would perhaps suggest that we first survey the material for how/to which extent we introduce context in the materials before this lesson, unless you already have done so?

Thanks for your thoughts. I've looked into where the repo uses the word "blocking" and it's only in these slides and one other place to describe a particular host_accessor behavior. Whereas synchronous terminology is used much more throughout the lessons. For example, lesson 4 talks about sync and async exceptions and lesson 9 is on asynchronous execution (these "Using USM" slides are lesson 8). So I think changing "this is a blocking operation" to "this is a synchronous operation" is consistent with the rest of the material.

I pushed a commit to drop the "It is unspecified whether free is blocking or non-blocking" extra bullet I added in the first PR comment. Aligned to that point of not having previously defining "blocking" in the lessons and it probably being too detailed a tangent.

Regarding contexts, Lesson 13 on multiple devices is introduces the concept of contexts in a reasonable amount of detail, so I added a reference to that lesson to try deffer attention on contents in this slide.

[illuhad]

Just requesting changes so that we don't forget that the WG made suggestions before merging.

[illuhad]

LGTM, thanks!