Yes it's been done before, and it requires fine tuning how many cep2 work units you allow on the host to be buffered and the overall buffer size so that 'other' projects fill the remaining cores. Given the horrible poor predictability of run times and more variables we/speak agent cannot control such as the dcf, it's not like set-and-forget. You'll have to monitor constantly.

No, you just specify the <max_concurrent> for cep2, no need to specify much more in app_config. The agent takes care to put other cores to work with whatever else there is in the q, if there is anything else in the q. Starvation of threads is possible in this scenario. On the device profile side you specify how many are allowed into your q, 1-16 or unltd. Then the tuning has to be done to make the cep2 tasks principally the oldest, so they always start first when any of the running 4 cep2 finishes. Remember in base the agent schedules fifo, only when there's chaos will it run earliest deadline first, more chance of the buffered cep2 in turn to go stale. If there's older of any of the other projects, they'll be started first, meaning you could still end up with fewer than 4 cep2 running.

Play and learn.