Is there a NativeContainer Attribute type that marks support full parallel write

I have working unsafe container named UnsafeParallelBuffer
Basically, any job can write any amount of any type of data into it.
It has a pre-thread data-block-chain to store data.
I am trying to use AtomicSafetyHandle to make a NativeParallelBuffer out of it.
But it looks like that nether [NativeContainerIsAtomicWriteOnly] nor [NativeContainerSupportsMinMaxWriteRestriction] fit to this case.
I want SafetyHandle in the ParallelWriter to throw exception only when there are previous reading jobs.
And SafetyHandle in the ParallelRead to throw exception when there's previous writing or reading jobs.
I don't want to throw exception when ParallelWriter is used in multiple Parallel jobs.As it is okay in my case because of the data-block-chain is per-thread by default.
But [NativeContainerIsAtomicWriteOnly] does not allow multiple jobs to that use the writer to schedule independently. And [NativeContainerSupportsMinMaxWriteRestriction] has a range limit where in my container there's no such limit at all.
For now, I have to mark [NativeDisableContainerSafetyRestriction] on my container. Losing all safety checks.

How can I solve this?
Source Attached.
P.S.The reason I am not using NativeStream is:

1. As it is meant to be used by EventSystem I can not estimate how many write batch is going to start.
2. I don't want to free and allocate Memory-Block-Chain every frame. as it is expensive. which with NativeStream I must do.

 

Facing the exact same challenge. This question is still relevant. How can we add safety to our per-thread-like buffers? Did you find a solution after all these years?

 

Bumping this thread again, ran in to the same issue.

 

I wonder why we can't have Native containers, at least for low intensity writing, that take out a lock on the accessor.

You know, a synchronized keyword accessor.
Oh wait, this is C# and C++, not Java.

So I mean lock(this)..., understand?
Like std::unique_lock<std::mutex> ..., right?

Yes it's slower to write, and will de-parallelize access, so it's only useful for low intensity write loads of a couple thousand accesses, or workloads that think a lot and then write one thing quickly, but that could be offloaded/deferred into a reduce step using the suggested mutex locking (omg, multithreaded reduce, what a concept).

 

It is possible to write custom locks for Unity's job system. You rarely want to do this, but if you elaborate on your use case, I may walk you through how.

 

Not me. I don't have a use case like that. (in this project / job / life, at least).