Hi Hyojin,
You are right, "conusming" is by default non-destructive and you can issue as many gets on the same item-instance as you want. In general, it is important to know that, in the abstract, the CnC model treats items
1. by value (and not by (object-)reference) and
2. as dynamic single assignment (DSA)
That's why the runtime issues the warning you see: Every item instance (identified by a tag) can be written only once (but it can be consumed mumltiple times). Hence, whenever semantically an item is altered and should be put for a other steps to be consumed, the altered "value" needs to be put with a different and unique tag.

BTW:
There is a garbage collection facility in the tuners called get_cout. If this is specified, the runtime will delete the item after it was "consumed" that many times. The tutorial (http://software.intel.com/sites/landingpage/icc/api/tutorial.html) explains this in more detail with an example. Some of the providedmore complex examples (like RTM and cholesky) combine smart-pointers and tuner::get_count to minimize the memory footprint and avoid unnecessary copying.

Does this help?

frank

The tuners don't have such a feature yet. We are designing a more powerfull tuning language, but that is also not yet available.

There are certainly ways to achieve what you want within the "domain" code. I don't know exaclty what your code is doing (e.g. what is the relation between the data and a step-tag and how do they get produced?), but I would really like to understand your motivation for wanting serial execution. Can you say a few words?

In any case, here are some random thoughts:
- using env-var CNC_NUM_THREADS=1 at runtime fully serializes the execution
- putting the next step-tag within the step itself just before exiting serializes execution of a certain step-collection
- an "artificial" producer-consumer relationship between two steps also forces the runtime to serialize

Quote:

how can I limit the number of items processed in parallel for a certain step? For example, regardless of how many items are ready, I'd like to process them one by one in a serialized fashion. I looked at the tuner interface, but couldn't find a way to limit the parallelism for an individual step collection. Thank you in advance!

That what I was trying to do with a "Log" class, that process each logged message in a delayed step (to not block the execution of the program): a message step can start only when the preceding message was processeced.
I get the trick with a step_tuner to setup the dependency, a dummy item_collection to populate the dependency, and an item_tuner to 'poping' the message queue. The complete code is attached (there's some codes / defines related to my framework, but nothing complicated).
Yey I know it's not some parallelized code, but it will be part of a much wider task based system, and in this case it makes sense!