<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<div></div>
Dear Jeff,
<div><br>
</div>
<div>thanks for taking care of the issue.</div>
<div>Sure your right about the signed vs. unsigned int stuff but i also tried it with long int : same result. Every integer in my code (memory manager) is long unsigned int, no reason to deal with negative sizes (at least from my perspective). I have an extended
version of this example which actually uses the window, sets it and checks it afterwards (but didn't post it to keep the source file small, also the issue is not with that part of the code). All sizes not exactly equal to 2^31 and some multiples of that work
very well and "df -h" on /dev/shm clearly shows that it is used correctly. Memory sizes returned by MPI_Win_shared_query also match the requested amount.</div>
<div><br>
</div>
<div>my installation is in /opt/mpi/ (which would mean i consider MPICH to be THE MPI) ;)</div>
<div>I still have to rename my source repo ~/git/openmpi though ;)</div>
<div><br>
</div>
<div>regards,</div>
<div>Steffen Weise</div>
<div><br>
</div>
<div>
<blockquote type="cite">
<div><br>
</div>
<div><br>
</div>
First, "long unsigned int window_size=2147483648" is not correct.<br>
They type you need to use there is MPI_Aint. The syntax of this<br>
function is<br>
<br>
int MPI_Win_allocate_shared(MPI_Aint size, int disp_unit, MPI_Info<br>
info, MPI_Comm comm, void *baseptr, MPI_Win *win)<br>
<br>
It may be true that "long unsigned int" is safely case to MPI_Aint,<br>
but that's a very danger way to write code and it may be broken on<br>
some platforms.<br>
<br>
In any case, everything above 2^31 is probably not okay. Unless<br>
absolutely every integer type used in the code paths you are hitting<br>
is size_t (or equivalent) and not int, you're going to hit overflow<br>
somewhere. Maybe I'm wrong, but you should verify (as a debugging<br>
mechanism, not in general) that MPI_Win_allocate_shared is behaving as<br>
desired by memset-ing the resulting data (mem) to verify that you're<br>
actually getting e.g. 2^34 bytes back. If /dev/shm is 4G, I'm not<br>
sure how that's possible but maybe the implementation doesn't use<br>
that.<br>
<br>
I'm going to be on a plane today but I'll run your code on my machine<br>
and try to figure out more about how "count-safe"<br>
MPI_Win_allocate_shared is.<br>
<br>
Jeff<br>
<br>
PS Installing MPICH in ~/git/openmpi is just dirty :-)<br>
<br>
On Fri, Jun 7, 2013 at 5:50 AM, Weise Steffen<br>
<<a href="mailto:Steffen.Weise@iec.tu-freiberg.de">Steffen.Weise@iec.tu-freiberg.de</a>> wrote:<br>
<blockquote type="cite">Dear mailing-list,<br>
<br>
this is my first time posting here. I found that with version 3.0.4 using MPI_Win_allocate_shared i get an error when using a size exactly 2^31 everything below and above is ok. Though i also had the same issue with 2^34. Some kind of division or type conversion
seems to be off. (/dev/shm has 4G so it is not a size issue.. i know what those errors look like)<br>
<br>
I attach my code and the output i get on a linux (debian 6.0) 64 bit machine (same issue on a mac though) .<br>
<br>
I'll be happy to provide more machine details or everything you guys need to analyse whats going on.<br>
<br>
with kind regards,<br>
Steffen Weise<br>
<br>
<br>
<br>
_______________________________________________<br>
discuss mailing list <a href="mailto:discuss@mpich.org">discuss@mpich.org</a><br>
To manage subscription options or unsubscribe:<br>
<a href="https://lists.mpich.org/mailman/listinfo/discuss">https://lists.mpich.org/mailman/listinfo/discuss</a><br>
</blockquote>
</blockquote>
<div><br>
</div>
</div>
</body>
</html>