Parallel execution problem

Help
,
1

i create a parallel execution example:

fn call_parallel(comptime T: type, comptime input: []const T, func: anytype) ![]T {
    var output: [input.len]T = undefined;
    var threads: [input.len]std.Thread = undefined;

    for (0..input.len) |x| {
        threads[x] = try std.Thread.spawn(.{}, func, .{ input[x], &output[x] });
    }
    for (0..input.len) |x| {
        threads[x].join();
    }

    return &output;
}

fn multiply(a: i32, b: *i32) void {
    b.* = (a * 5);
    std.debug.print("in: {d} out: {d}\n", .{ a, b.* });
}

pub fn main() !void {
    const input = [_]i32{ 1, 2, 3, 4, 5, 6, 7, 8 };

    const out = try call_parallel(i32, &input, multiply);
    for (out) |item| {
        std.debug.print("item: {d}\n", .{item});
    }
}

my zig version: 0.14.1
this code output:

in: 1 out: 5
in: 2 out: 10
in: 5 out: 25
in: 4 out: 20
in: 3 out: 15
in: 6 out: 30
in: 7 out: 35
in: 8 out: 40
item: 5
item: 1
item: 3296236
item: 1
item: 1873782352
item: 1
item: 3204752
item: 1

As you can see output looks junk codes. how can i fix this? (I use mac aarch64)

2

You return a pointer to stack allocated memory, just return the array instead by value.

So I would change the return type to ![input.len]T and return output.

4 Likes
3

Edit: @Sze was quicker with a more complete answer. :heart:

1 Like
4

thank you , you are right and i figure out this if i send output array to call_parallel it works too, but

  1. why compiler don’t warn me like rust? is it any special parameter for this?
  2. how can i change []const T to []T or vise verse ? is there a special @cast for this?
  3. is there a doc or page explain this reach ways for example []*const T, []*T, [*:0]T … ?
5

  1. It is planned to get more safety checking for errors like this, Rust avoids having to deal with the same problem by disallowing the types of programs that could contain this sort of error (which also disallows some programs which may not contain an error), while Zig doesn’t want to disallow you from writing programs just because it can’t prove that they are safe.

    Basically Rust has a more extreme focus on safety, sacrificing what a user is allowed to do, while Zig allows you more freedom, it also means more responsibility. It is planned to have safety checks and ways to avoid these errors, but those aren’t fully implemented yet. These sort of errors also happen the most for newcomers to the language, which is unfortunate, but also means they are normally only a big source of errors until the person got more familiar with the language.

  2. You can pass []T to a parameter that expects []const T this means that you are passing a non const slice to a function that will treat it as const, you don’t need a cast for that. It is a bad idea to cast []const T to []T, because when you don’t know what you are doing you can create a segmentation fault or maybe even worse, when trying to modify memory that wasn’t supposed to be modified.
    Things that are const can be located in read-only memory, removing their const qualifiers and mutating them can cause errors/crashes/invariant-being-broken/Illegal-Behavior.
    You only can safely remove a const when your program created the thing in a way where it originally wasn’t const, for that you can use @constCast. Often there is a way to avoid needing to use @constCast, for example by holding on to the originally mutable pointer.

  3. Please rephrase I don’t understand the question.

Also checkout the docs section in this forum, for example:

And btw. welcome to Ziggit!

2 Likes
6

thank you again, i will checkout your docs.