Cool idea!
This should instead be:
last = atomic_sub!(busy, UInt(1))
if last == 1
Because otherwise between the modify and read operations it’s possible for the value to change (unlikely, but semantically possible).
Instead of:
try to use:
lock(done)
notify(done)
end
in case notify throws an error (I have no clue if it can, but it’s good practice).
If you have to do this, it’s usually an indication that you’re doing something wrong. You should try to structure put!(ch, y) so that it can be called immediately after construction. Relying on the sleep approach to ensure that your tasks are scheduled will potentially become a source of bugs in the future.
And in your tests:
You probably meant vcat(outputs...) 
Otherwise this seems generally fine to me! You could also consider using Dagger to distribute this work, assuming you only submit functional programs (no side effects or mutating inputs).