release operation isn't launched after read-only task about legion HOT 5 CLOSED

You're right, the release won't be performed until after the read-only task returns unless specific conditions are met, such as the read-only task is using a different physical instance from the one the release operation will be copying dirty data to as part of the release. It's a standard WAR dependence. Since it looks like you didn't implement a custom mapper, it's unlikely that you're ensuring that they are going to different physical instances using the WAR flag. You need to prove to me that the read-only tasks are using a different physical instance from the one being targeted by the release before I'll look into this further.

from legion.

I have added a custom mapper for read_write test. The mapper enables WAR flag for both read_only and read_write tasks. The testcase always acquires the logical region before launching every read_only (or read_write) task, while those tasks require in-memory physical instances, so I would expect runtime could perform WAR optimizations for read_only and read_write tasks.

BTW, it seems Legion runtime still serializes all tasks, but I cannot debug this with legion_spy. The error message I got indicates that HLR didn't log physical region creation for attach operation.

from legion.

Two things to check:

1. You are unmapping the 'attached' region before you do any of these task calls right? Otherwise the runtime is issuing inline unmap/remap calls around every task call which we definitely account for your serialization.
2. In your custom mapper, you are actually mapping tasks to different processors?

Also, how do you know you are not getting parallel execution?

from legion.

I have updated the custom mapper in attach-file branch:

1. Yes, I have unmapped the attached region before launching subtasks.
2. In current mapper, all read_only and read_write tasks are mapped to different processors.

It seems legion_spy doesn't log physical instance creation for attach-file. I am using legion_prof to debug this right now. Following link shows an execution of read_write test. All tasks mapped to the first proc are read_only task, while all other tasks are mapped to the last proc.
http://stanford.edu/~zhihao/legion_prof.html

from legion.

The problem was that the leaf tasks in the 'read_write' test were not actually marked as a leaf task, which practically prevented WAR optimization from being applied. Closed by commit 8142726.

from legion.