Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Concurrent thread limit #28

Open
H0neyBadger opened this issue May 1, 2020 · 3 comments
Open

Concurrent thread limit #28

H0neyBadger opened this issue May 1, 2020 · 3 comments

Comments

@H0neyBadger
Copy link

Hello,
I m currently facing an issue with the pthread interface.

Despite mutex/barrier and sched_yield some threads never execute after reaching a specific number. Some threads are like frozen (hanged).

The number of running concurrent threads look limited for the homebrew process.
Is there a way to increase this limit ?

I created the following snippet to test this problem.
https://gist.github.com/H0neyBadger/c080dd00c0dd77439bd8d41826d49d0c#file-main-cpp-L131
With thread count to 68, the job is running as expected.
With thread count to 69 (or greater) one or many threads are frozen. The thread barrier is never reached.

I m using nxlink and homebrew netloader to test my projects (with the latest devkitpro pacman on arch).

I spent a lot of time on this issue, and I m out of idea.
I hope you can help

P.S: I initially posted my issue on newlib project
devkitPro/newlib#20

@fincs
Copy link
Contributor

fincs commented May 1, 2020

We are looking into it right now, it looks like AMS might be the source of this bug. I have a question for you, are you running homebrew in applet mode, or are you using an application?

@H0neyBadger
Copy link
Author

H0neyBadger commented May 1, 2020

I m running in applet mode (by default)
(applet mode)
"thread_cur_value: 28, thread_lim_value: 96"
(application)
"thread_cur_value: 1, thread_lim_value: 96"

but with count of 69, threads remain frozen in application mode.
(but it might be an other issue related to printf consoleUpdate high rate. I m triple checking my code currently)

@H0neyBadger
Copy link
Author

Using application mode do the trick for the gist snippet.
But my WIP project still freezing on thread allocation (with ~5 threads)
Getting rid of the "nxlink" part is usually enough to let the code run normally.
Is there another metric test to watch like stack/heap/socket usage ?
thanks

my current socket config there is currently 2 sockets/thread (~10 socket total):

static const SocketInitConfig g_chiakiSocketInitConfig = {
    .bsdsockets_version = 1,

    .tcp_tx_buf_size = 0x8000,
    .tcp_rx_buf_size = 0x10000,
    .tcp_tx_buf_max_size = 0x40000,
    .tcp_rx_buf_max_size = 0x40000,

    .udp_tx_buf_size = 0x40000,
    .udp_rx_buf_size = 0x40000,

    .sb_efficiency = 8,

    .num_bsd_sessions = 16,
    .bsd_service_type = BsdServiceType_User,
};

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants