Merge pull request #92 from scheduler-tools/fix-barrier

barrier: fix waiting event with multi instances tasks

doc/tutorial.txt

@@ -493,7 +493,9 @@ however, using a pthread_barrier would impose some strict conditions on usage
 around thread cleanups - primarily that you cannot cancel an in-progress barrier
 operation which would mean that we have to restrict cleanup to only be possible
 at the end of a loop cycle (i.e. all phases are complete). This would be too
-restrictive for most uses so here we use an alternative.
+restrictive for most uses so here we use an alternative. Finally, barrier can't
+be used with fork event because we must know how many threads will wait which
+is not possible with fork events.
 
 In this implementation, the barrier event manages its own mutex and uses a
 variable shared between users to track waiting tasks, protected by the mutex.

src/rt-app_parse_config.c

@@ -572,7 +572,7 @@ parse_task_event_data(char *name, struct json_object *obj,
 
 		data->res = i;
 		rdata = &((*resources_table)->resources[data->res]);
-		rdata->res.barrier.waiting += 1;
+		rdata->res.barrier.waiting += tdata->num_instances;
 
 		log_info(PIN2 "type %d target %s [%d] %d users so far", data->type, rdata->name, rdata->index, rdata->res.barrier.waiting);
 		snprintf(data->name, sizeof(data->name)-1, "%s:%s",