Rule for making @threads not recommended

[iuliadmtru]

According to this blogpost, Threads.@threads should not be used without :static, or at all, preferring working directly with tasks using Threads.@spawn. I added a rule that searches for uses of Threads.@threads, but not for Threads.@threads :static.

When running semgrep -c on the .yml and .jl files, there are three matches:

threads.threads-macro                                                         
          Using `Threads.@threads` can possibly lead to concurrency bugs. Use `Threads.@threads
          :static` instead or work directly with `Threads.@spawn` to create and manage tasks.  
                                                                                               
            6┆ Threads.@threads for i = 1:10
            7┆     a[i] = Threads.threadid()
            ⋮┆----------------------------------------
            6┆ Threads.@threads for i = 1:10
            7┆     a[i] = Threads.threadid()
            ⋮┆----------------------------------------
           11┆ @threads for i = 1:10
           12┆     a[i] = threadid()

Lines 6-7 are matched two times. This is because of the pattern-either rule. This rule would not be necessary if Semgrep would support matching wildcard imports (such as using Threads), making @threads be recognisable as Threads.@threads and removing the need for checking both patterns. I understand from @brandonspark that they are working on making this possible.

Also, I don't understand why the end line won't match as well (why, for example, doesn't the rule match lines 6-8 instead of just 6-7). But I don't think that's a big problem.

[KristofferC]

According to this blogpost, Threads.@threads should not be used without :static, or at all, preferring working directly with tasks using Threads.@Spawn.

That seems a bit strong. As long as you don't have a "work cache" that you try to index with the thread id it should be fine. The default for @threads was changed from :static to :dynamic since :dynamic has in general better performance since you are not a priori deciding what threads will work on different chunks of the data.

[iuliadmtru]

I must have misunderstood the discussion. I think the other PR I did is what you mean?

Also, do I understand correctly that nthreads() should stop being used?

[aviks]

While there is some discussion that @threads should be deprecated in favour of something else, that doesn't seem to be consensus opinion.