OpenMP parallel function calling on object iteration











up vote
0
down vote

favorite












I'm having problems parallelising the calling of a member function in a for loop. I only want to parallelise the iteration of objects, not the iteration of vectors within the called function.



This is how i call the parallel section, where particle_vector is a vector of objects and build_state_pylist() is a member function. state_vec and state_pylist are both object members.



#pragma omp parallel for
for (int i=0; i < n_sims; ++i) {
particle_vector[i].build_state_pylist();
}


build_state_pylist() iterates through values of state_vec, which is a std::vector of vectors. The contained values and appending them to state_pylist, a boost::python::list, which is a member of the object.



void Particle::build_state_pylist() {
for (auto sim_iter = state_vec.begin(); sim_iter != state_vec.end(); ++sim_iter) {
auto sim_vec = *sim_iter;
for (auto vec_iter= sim_vec.begin(); vec_iter!= sim_vec.end(); ++vec_iter) {
this->state_pylist.append(*vec_iter);
}
}


}



Since the each loop iteration is only accessing memory contained within each object I didn't think parallelising this section would be a problem. But I get this error:



double free or corruption (!prev)


and



(core dumped)


The loop works without parallelisation. Any help would be greatly appreciated!










share|improve this question


















  • 2




    This cannot be answered without seeing more code, the problem is likely somewhere deep inside. Are you 100% sure that there is no shared resource accessed by multiple threads within Particle::build_state_pylist()?
    – Daniel Langr
    Nov 8 at 11:46






  • 1




    Also, couldn't this issue be related to your problem: boost.python not supporting parallelism? See also the documentation: wiki.python.org/moin/boost.python/…
    – Daniel Langr
    Nov 8 at 11:51












  • Within Particle::build_state_pylist(), the resources being accessed are state_vec and state_pylist. Both of which are object members, so I'm not sure why they would be shared across threads. edit: I'll look into the boost parallel support!
    – Behzad
    Nov 8 at 11:55












  • It's difficult to answer your question without having a minimal example to reproduce the issue. If you didn't already, you could try tools like Clang's Thread Sanitizer to have more information on the eventual data race.
    – Massimiliano
    Nov 14 at 19:51















up vote
0
down vote

favorite












I'm having problems parallelising the calling of a member function in a for loop. I only want to parallelise the iteration of objects, not the iteration of vectors within the called function.



This is how i call the parallel section, where particle_vector is a vector of objects and build_state_pylist() is a member function. state_vec and state_pylist are both object members.



#pragma omp parallel for
for (int i=0; i < n_sims; ++i) {
particle_vector[i].build_state_pylist();
}


build_state_pylist() iterates through values of state_vec, which is a std::vector of vectors. The contained values and appending them to state_pylist, a boost::python::list, which is a member of the object.



void Particle::build_state_pylist() {
for (auto sim_iter = state_vec.begin(); sim_iter != state_vec.end(); ++sim_iter) {
auto sim_vec = *sim_iter;
for (auto vec_iter= sim_vec.begin(); vec_iter!= sim_vec.end(); ++vec_iter) {
this->state_pylist.append(*vec_iter);
}
}


}



Since the each loop iteration is only accessing memory contained within each object I didn't think parallelising this section would be a problem. But I get this error:



double free or corruption (!prev)


and



(core dumped)


The loop works without parallelisation. Any help would be greatly appreciated!










share|improve this question


















  • 2




    This cannot be answered without seeing more code, the problem is likely somewhere deep inside. Are you 100% sure that there is no shared resource accessed by multiple threads within Particle::build_state_pylist()?
    – Daniel Langr
    Nov 8 at 11:46






  • 1




    Also, couldn't this issue be related to your problem: boost.python not supporting parallelism? See also the documentation: wiki.python.org/moin/boost.python/…
    – Daniel Langr
    Nov 8 at 11:51












  • Within Particle::build_state_pylist(), the resources being accessed are state_vec and state_pylist. Both of which are object members, so I'm not sure why they would be shared across threads. edit: I'll look into the boost parallel support!
    – Behzad
    Nov 8 at 11:55












  • It's difficult to answer your question without having a minimal example to reproduce the issue. If you didn't already, you could try tools like Clang's Thread Sanitizer to have more information on the eventual data race.
    – Massimiliano
    Nov 14 at 19:51













up vote
0
down vote

favorite









up vote
0
down vote

favorite











I'm having problems parallelising the calling of a member function in a for loop. I only want to parallelise the iteration of objects, not the iteration of vectors within the called function.



This is how i call the parallel section, where particle_vector is a vector of objects and build_state_pylist() is a member function. state_vec and state_pylist are both object members.



#pragma omp parallel for
for (int i=0; i < n_sims; ++i) {
particle_vector[i].build_state_pylist();
}


build_state_pylist() iterates through values of state_vec, which is a std::vector of vectors. The contained values and appending them to state_pylist, a boost::python::list, which is a member of the object.



void Particle::build_state_pylist() {
for (auto sim_iter = state_vec.begin(); sim_iter != state_vec.end(); ++sim_iter) {
auto sim_vec = *sim_iter;
for (auto vec_iter= sim_vec.begin(); vec_iter!= sim_vec.end(); ++vec_iter) {
this->state_pylist.append(*vec_iter);
}
}


}



Since the each loop iteration is only accessing memory contained within each object I didn't think parallelising this section would be a problem. But I get this error:



double free or corruption (!prev)


and



(core dumped)


The loop works without parallelisation. Any help would be greatly appreciated!










share|improve this question













I'm having problems parallelising the calling of a member function in a for loop. I only want to parallelise the iteration of objects, not the iteration of vectors within the called function.



This is how i call the parallel section, where particle_vector is a vector of objects and build_state_pylist() is a member function. state_vec and state_pylist are both object members.



#pragma omp parallel for
for (int i=0; i < n_sims; ++i) {
particle_vector[i].build_state_pylist();
}


build_state_pylist() iterates through values of state_vec, which is a std::vector of vectors. The contained values and appending them to state_pylist, a boost::python::list, which is a member of the object.



void Particle::build_state_pylist() {
for (auto sim_iter = state_vec.begin(); sim_iter != state_vec.end(); ++sim_iter) {
auto sim_vec = *sim_iter;
for (auto vec_iter= sim_vec.begin(); vec_iter!= sim_vec.end(); ++vec_iter) {
this->state_pylist.append(*vec_iter);
}
}


}



Since the each loop iteration is only accessing memory contained within each object I didn't think parallelising this section would be a problem. But I get this error:



double free or corruption (!prev)


and



(core dumped)


The loop works without parallelisation. Any help would be greatly appreciated!







c++ boost parallel-processing openmp






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 8 at 11:13









Behzad

5617




5617








  • 2




    This cannot be answered without seeing more code, the problem is likely somewhere deep inside. Are you 100% sure that there is no shared resource accessed by multiple threads within Particle::build_state_pylist()?
    – Daniel Langr
    Nov 8 at 11:46






  • 1




    Also, couldn't this issue be related to your problem: boost.python not supporting parallelism? See also the documentation: wiki.python.org/moin/boost.python/…
    – Daniel Langr
    Nov 8 at 11:51












  • Within Particle::build_state_pylist(), the resources being accessed are state_vec and state_pylist. Both of which are object members, so I'm not sure why they would be shared across threads. edit: I'll look into the boost parallel support!
    – Behzad
    Nov 8 at 11:55












  • It's difficult to answer your question without having a minimal example to reproduce the issue. If you didn't already, you could try tools like Clang's Thread Sanitizer to have more information on the eventual data race.
    – Massimiliano
    Nov 14 at 19:51














  • 2




    This cannot be answered without seeing more code, the problem is likely somewhere deep inside. Are you 100% sure that there is no shared resource accessed by multiple threads within Particle::build_state_pylist()?
    – Daniel Langr
    Nov 8 at 11:46






  • 1




    Also, couldn't this issue be related to your problem: boost.python not supporting parallelism? See also the documentation: wiki.python.org/moin/boost.python/…
    – Daniel Langr
    Nov 8 at 11:51












  • Within Particle::build_state_pylist(), the resources being accessed are state_vec and state_pylist. Both of which are object members, so I'm not sure why they would be shared across threads. edit: I'll look into the boost parallel support!
    – Behzad
    Nov 8 at 11:55












  • It's difficult to answer your question without having a minimal example to reproduce the issue. If you didn't already, you could try tools like Clang's Thread Sanitizer to have more information on the eventual data race.
    – Massimiliano
    Nov 14 at 19:51








2




2




This cannot be answered without seeing more code, the problem is likely somewhere deep inside. Are you 100% sure that there is no shared resource accessed by multiple threads within Particle::build_state_pylist()?
– Daniel Langr
Nov 8 at 11:46




This cannot be answered without seeing more code, the problem is likely somewhere deep inside. Are you 100% sure that there is no shared resource accessed by multiple threads within Particle::build_state_pylist()?
– Daniel Langr
Nov 8 at 11:46




1




1




Also, couldn't this issue be related to your problem: boost.python not supporting parallelism? See also the documentation: wiki.python.org/moin/boost.python/…
– Daniel Langr
Nov 8 at 11:51






Also, couldn't this issue be related to your problem: boost.python not supporting parallelism? See also the documentation: wiki.python.org/moin/boost.python/…
– Daniel Langr
Nov 8 at 11:51














Within Particle::build_state_pylist(), the resources being accessed are state_vec and state_pylist. Both of which are object members, so I'm not sure why they would be shared across threads. edit: I'll look into the boost parallel support!
– Behzad
Nov 8 at 11:55






Within Particle::build_state_pylist(), the resources being accessed are state_vec and state_pylist. Both of which are object members, so I'm not sure why they would be shared across threads. edit: I'll look into the boost parallel support!
– Behzad
Nov 8 at 11:55














It's difficult to answer your question without having a minimal example to reproduce the issue. If you didn't already, you could try tools like Clang's Thread Sanitizer to have more information on the eventual data race.
– Massimiliano
Nov 14 at 19:51




It's difficult to answer your question without having a minimal example to reproduce the issue. If you didn't already, you could try tools like Clang's Thread Sanitizer to have more information on the eventual data race.
– Massimiliano
Nov 14 at 19:51

















active

oldest

votes











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














 

draft saved


draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53206605%2fopenmp-parallel-function-calling-on-object-iteration%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown






























active

oldest

votes













active

oldest

votes









active

oldest

votes






active

oldest

votes
















 

draft saved


draft discarded



















































 


draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53206605%2fopenmp-parallel-function-calling-on-object-iteration%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Schultheiß

Verwaltungsgliederung Dänemarks

Liste der Kulturdenkmale in Wilsdruff