mtsieve

[unconnected]

Originally Posted by rogue

Since you are building on your own, you can comment out the code in the SharedMemoryItem.cpp class in the TryLock(), Lock(), and Release() methods and rebuild. This will only work if you have 1 worker.

If you have any debugging experience, a stack trace would be helpful.

Mark, I've added debug printf to Lock() and found that in case of error return code is 35 (EDEADLK):

The pthread_mutex_lock() function may fail if: 
EDEADLK The current thread already owns the mutex.

Commenting methods didn't help - source successfully compiled and ran but no sieve at all, only removed algebraic factors.

[Happy5214]

Originally Posted by unconnected

Mark, I've added debug printf to Lock() and found that in case of error return code is 35 (EDEADLK):

The pthread_mutex_lock() function may fail if: 
EDEADLK The current thread already owns the mutex.

Commenting methods didn't help - source successfully compiled and ran but no sieve at all, only removed algebraic factors.

The offending code appears to be core/Worker.cpp, lines 164-167:

   SetHasWorkToDo();
   
   // 
   ip_WorkerStatus->Release();

The lock is being released after the worker status is changed, so the first method ends up re-locking the mutex. Flipping the two commands fixed the error for me.

[rogue]

Originally Posted by Happy5214

The offending code appears to be core/Worker.cpp, lines 164-167:

   SetHasWorkToDo();
   
   // 
   ip_WorkerStatus->Release();

The lock is being released after the worker status is changed, so the first method ends up re-locking the mutex. Flipping the two commands fixed the error for me.

Great catch, but the proper fix is to modify Worker.h. SetHasWorkToDo() should call ip_WorkerStatus->SetValueHaveLock(). This is because the method is called when the thread already has a lock on the ip_WorkerStatus object. This method releases that lock after it has built the collection of primes for the thread.

I wonder why Windows doesn't catch this.

[Happy5214]

Originally Posted by rogue

Great catch, but the proper fix is to modify Worker.h. SetHasWorkToDo() should call ip_WorkerStatus->SetValueHaveLock(). This is because the method is called when the thread already has a lock on the ip_WorkerStatus object. This method releases that lock after it has built the collection of primes for the thread.

I wonder why Windows doesn't catch this.

From the Microsoft documentation on EnterCriticalSection:

After a thread has ownership of a critical section, it can make additional calls to EnterCriticalSection or TryEnterCriticalSection without blocking its execution. This prevents a thread from deadlocking itself while waiting for a critical section that it already owns. The thread enters the critical section each time EnterCriticalSection and TryEnterCriticalSection succeed. A thread must call LeaveCriticalSection once for each time that it entered the critical section.

I take this to mean that repeated calls don't result in an error, unlike pthreads.

[rogue]

Originally Posted by Happy5214

From the Microsoft documentation on EnterCriticalSection:

I take this to mean that repeated calls don't result in an error, unlike pthreads.

Yet another reason to dislike Windows. Thanks for finding the reason.

[Dylan14]

A suggestion: when using the -A (or the --applyandexit flag), assume that if there is no file given with -I, assume that the factors are given in a file called "factors.txt", or warn the user that the switch requires a file name to be given with -I to work.

[rogue]

Originally Posted by Dylan14

A suggestion: when using the -A (or the --applyandexit flag), assume that if there is no file given with -I, assume that the factors are given in a file called "factors.txt", or warn the user that the switch requires a file name to be given with -I to work.

Seems reasonable

[rogue]

I posted 1.9.6. I was sitting on it for a while as I forgot to post. Here are the changes:

• Fixed issue in srsieve2 where it crashes when starting a new sieve.
• Fixed issue in srsieve2 where it finds an invalid factor and terminates.
• Refactored logic for "single worker" and "rebuild" logic so they work more nicely together.
• Fixed calculation of p/sec which is wrong after workers are recreated.
• Feset factor stats whenever workers are created as the rate is inflated for lower p as far more terms are removed.
• Fix issue with multiple threads which can cause program to hang.
• Add support for ABC format to srsieve2.

[JeppeSN]

Silly question: Which is the preferred place to download from if I only care about the Windows (x64) binaries, not the source?

On https://www.mersenneforum.org/rogue/mtsieve.html there is a file with 1.9.6 in its name. The version history on that html page does not go further than 1.7.3.

On https://sourceforge.net/projects/mtsieve/ there is a file with 1.9.7 in its name. Does it include both source and binaries? Is this a "beta" or "unreleased" version?

The README_MTSieve.txt file refers to the former of these two web sites.

/JeppeSN

[rogue]

Originally Posted by JeppeSN

Silly question: Which is the preferred place to download from if I only care about the Windows (x64) binaries, not the source?

On https://www.mersenneforum.org/rogue/mtsieve.html there is a file with 1.9.6 in its name. The version history on that html page does not go further than 1.7.3.

On https://sourceforge.net/projects/mtsieve/ there is a file with 1.9.7 in its name. Does it include both source and binaries? Is this a "beta" or "unreleased" version?

The README_MTSieve.txt file refers to the former of these two web sites.

/JeppeSN

Sorry about the confusion. 1.9.6 and 1.9.7 are the same. I misnamed it because the version in the changes.txt file was incorrect. The file is named incorrectly on the one webpage. I need to change that to point to sourceforge.

[pepi37]

I have found small error ( if we can call it error) In latest twinsieve release if we set -P 10000000 it only sieve up to 10007. I believe it has some connection with chunks ( number of worker or so) So that is nearly cosmetic error. On higher P limit everything is OK
Can you also add in info line cpu usage in percentage?