Multi sched read

[marioskogias]

No description provided.

[mjp41]

This is looks good. Here are some minor comments as I tried to understand the code.

[mjp41]

I wonder if we should have some more racy tests. Where there are concurrent attempts to schedule, and hence concurrent potential wake and schedule, and sleep. We don't seem to cover those cases here.

[mjp41]

Update the comment

[mjp41]

I wonder if this would be a little clearer:

Suggested change

	auto last_slot = std::get<1>(cown_to_behaviour_slot_map[i]);
	size_t first_body_index = std::get<0>(cown_to_behaviour_slot_map[i]);
	auto first_slot = last_slot;
	// The number of RCs provided for the current cown by the when.
	// I.e. how many moves of cown_refs there were.
	size_t transfer_count = last_slot->is_move();
	auto all_reads = last_slot->is_read_only();
	Logging::cout() << "Processing " << cown << " " << body << " "
	<< last_slot << " Index " << i << Logging::endl;
	auto first_slot = std::get<1>(cown_to_behaviour_slot_map[i]);
	size_t first_body_index = std::get<0>(cown_to_behaviour_slot_map[i]);
	// The number of RCs provided for the current cown by the when.
	// I.e. how many moves of cown_refs there were.
	size_t transfer_count = first_slot->is_move();
	auto all_reads = first_slot->is_read_only();
	Logging::cout() << "Processing " << cown << " " << body << " "
	<< first_slot << " Index " << i << Logging::endl;
	auto last_slot = first_slot;

I also wonder if we should rename last_slot to curr_slot? That makes it clear it is varying during the loop.

[mjp41]

I wonder if this would be slightly clearer?

Suggested change

	size_t first_consecutive_readers_count = all_reads;
	size_t first_consecutive_readers_count = all_reads? 1 : 0;

[mjp41]

I wonder if direct returns in this code would be clearer.

Suggested change

	goto fn_out;
	return {0, 0};

I'm also not sure I get the usage of ex_count here. This is that all the reads in this chain have seen a READ_AVAILABLE, so they can all decrease there execution count by 1?

[mjp41]

Why is ex_count not used here? It feels like the whole chain should get to go if the read available was seen during scheduling, but otherwise it shouldn't? Doesn't this increase the count on the chain apart from the first entry, if read available wasn't seen?

[mjp41]

Can ex_count be anything other than 0 in this branch?

Suggested change

	{
	Logging::cout() << " Writer at head of queue and got the cown "
	<< *curr_slot << Logging::endl;
	<< *chain_first_slot << Logging::endl;
	ex_count++;
	yield();
	}
	{
	Logging::cout() << " Writer at head of queue and got the cown "
	<< *chain_first_slot << Logging::endl;
	ec[first_body_index] += 1;
	yield();
	continue;
	}

[mjp41]

If we can treat ex_count as a read chain that observed the read was available. Could we do this? Perhaps with a rename of ex_count?

Suggested change

	// Process execution count
	ec[first_body_index] += ex_count;
	for (int i = 1; i < first_consecutive_readers_count; i++)
	ec[first_body_index + i] += 1;
	}
	// Process execution count
	if (ex_count != 0)
	{
	for (int i = 0; i < first_consecutive_readers_count; i++)
	ec[first_body_index + i] += 1;
	}
	}