[petsc-dev] Adding support memkind allocators in PETSc

[Jed Brown]

Barry Smith <bsmith at mcs.anl.gov> writes:
>   For things like we talked about the other day. Malloc zones,
>   .... maybe some indication that it is ok that the runtime take back
>   this memory if available memory is running low, 

How do you communicate to the accessor that the memory has been freed?

>   the ability to turn off read or all access to a malloc zone so that
>   another library cannot corrupt the data, etc. When I said
>   independent of memkind I meant having nothing to do with memkind.

Sure, and I'm not opposed to the concept, but I'd like it to somehow be
based on information that the caller can use and have semantics that are
implementable.  I'm also not wild about the global variables like
PETSC_COMM_WORLD (whose use is pretty much always wrong in library
code), so would like to know how a relevant context would be plumbed
into the caller's scope.

>   You are correct that involves lots of nonlocal information or information that is not yet known, so the argument cannot be simple flags but must be a context that can be modified at later times.  Crude example
>
>   malloc(zone1, n,&x);
>    ....
>   ZoneSetReadOnly(zone1);

This is implementable, just somewhat expensive.

>   ZoneSetAvailableIfNeeded(zone1);

I don't know what semantics this could have that wouldn't be a
programming disaster.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20150428/1d90831f/attachment.sig>