SA-MP Forums

Go Back   SA-MP Forums > SA-MP Scripting and Plugins > Plugin Development

Reply
 
Thread Tools Display Modes
Old 25/07/2013, 09:59 PM   #11
Johnson_boy
Huge Clucker
 
Join Date: Mar 2011
Location: Finland
Posts: 215
Reputation: 80
Default Re: AW: Bcrypt

Quote:
Originally Posted by BigETI View Post
Ouch STL containers are not really thread safe. I've experimented with threads (from WINAPI) once, and it just accessed bad memory while the first thread was inserting information and the second one attempted to read it.

Also you are creating threads after the native function gets called. Realize your server attempts to call this native several times, and you are creating too many threads at once (again this can crash your application)
I decided to test this by calling bcrypt_hash (work factor 12) 400 times with a for loop. The server did not crash and calculated the hash for each call. It might be that the server crashes if even more concurrent threads are created, but I really doubt that's going to happen under normal circumstances.


Edit: As to the issue with thread safety, what would you recommend as a solution? Based on quick research, the use of mutexes seems promising.

Last edited by Johnson_boy; 25/07/2013 at 10:38 PM.
Johnson_boy is offline   Reply With Quote
Old 26/07/2013, 03:09 AM   #12
Red_Dragon.
High-roller
 
Red_Dragon.'s Avatar
 
Join Date: Sep 2012
Posts: 1,390
Reputation: 46
Default Re: Bcrypt

Happy to see this finally in a plugin!
Red_Dragon. is offline   Reply With Quote
Old 26/07/2013, 07:12 AM   #13
Dan..
Gangsta
 
Join Date: Jun 2012
Location: Galati, Romania
Posts: 521
Reputation: 122
Default Re: Bcrypt

Suggestions:

http://www.boost.org/doc/libs/1_54_0...free.queue_hpp

Don't use more than 2 threads.

Implement a blocking function aswell for those having powerful servers.

Make `cost` a default parameter. Also, playerid parameter is useless, you'd better add an "threadidex" parameter.
pawn Code:
native bcrypt_hash(threadid, threadidex, password[], cost = 4);
Also, this means that you have to change the callback:
pawn Code:
forward OnBcryptHashed(threadid, threadidex, password[], hash[]);
__________________
I'm no longer visiting these forums. BlueG, you can suck my dick.
Dan.. is offline   Reply With Quote
Old 26/07/2013, 07:20 AM   #14
Niko_boy
High-roller
 
Niko_boy's Avatar
 
Join Date: Aug 2010
Location: Somewhere i belong
Posts: 1,336
Reputation: 138
Default Re: Bcrypt

nice another hashin implementation
good will give ti a shot!
__________________
nope[IMG]http://*******/1r0SOkH_[/IMG]
•••[CLOSED]LCS•Freeroam•DM•Stunts•••AutoArena [0.3z][No SkinShot][sixtytiger.com]Want a decent Attack Defend Gamemode?
N/A176.31.229.148:7830Get This! Attack-Defend(v2.3.1)
Niko_boy is offline   Reply With Quote
Old 26/07/2013, 05:23 PM   #15
Johnson_boy
Huge Clucker
 
Join Date: Mar 2011
Location: Finland
Posts: 215
Reputation: 80
Default Re: Bcrypt

I decided to use std::lock_guard to overcome the issue with vector's thread safety. It seemed the most suitable and secure solution (unlocks even on exceptions)

Quote:
Originally Posted by Dan.. View Post
Suggestions:

http://www.boost.org/doc/libs/1_54_0...free.queue_hpp

Don't use more than 2 threads.

Implement a blocking function aswell for those having powerful servers.

Make `cost` a default parameter. Also, playerid parameter is useless, you'd better add an "threadidex" parameter.
pawn Code:
native bcrypt_hash(threadid, threadidex, password[], cost = 4);
Also, this means that you have to change the callback:
pawn Code:
forward OnBcryptHashed(threadid, threadidex, password[], hash[]);
Thanks for the suggestions.

I added the default cost and changed playerid to thread_idx.

About limiting the amount of threads used to 2: Why should this be done? Does it increase stability?
Johnson_boy is offline   Reply With Quote
Old 26/07/2013, 06:27 PM   #16
Dan..
Gangsta
 
Join Date: Jun 2012
Location: Galati, Romania
Posts: 521
Reputation: 122
Default Re: Bcrypt

The amount of resources wasted creating a new thread, executing it parallelly, collecting the result (there is a mutex that will waste a little more), sending it back to the main thread, killing the thread is way too big. You shouldn't need more than two threads (SA-MP's ProcessTick - to communicate with the AMX and another one for computing).
__________________
I'm no longer visiting these forums. BlueG, you can suck my dick.

Last edited by Dan..; 27/07/2013 at 07:51 AM.
Dan.. is offline   Reply With Quote
Old 26/07/2013, 11:32 PM   #17
BigETI
Banned
 
Join Date: Mar 2010
Location: Germany
Posts: 1,046
Reputation: 359
Default AW: Re: Bcrypt

Quote:
Originally Posted by ****** View Post
I would actually disagree with that. Creating threads does have a lot of overhead, but if you can create a pool of workers somewhat equal to the virtual cores on your machine then you will improve performance with more than 2.
You can't compare this situation to real life workers. Believe me or not for some unknown reason at some point it will behave weird, especially if you are working with dynamic memory. I can rely on facts I've collected by doing tests on multiple threads. I've made once a test application running at 3 threads (all threads include an inner infinite loop for processing 3 tasks at once all the time). No STL containers was involved, but at some point suddenly you access bad memory by even testing pointers for not returning zero. However at using 2 threads, it was running quite harmless (Yes, I am still using a dual core processor). Also you have to decide how many threads you want to use at once, because a processor with 2, 4, 6 or 8 cores can only work efficient at the amount of current important threads equals the amount of cores a processor has. I don't know what is more efficient, but are 8 threads doing something on a dual core processor more efficient than 4 threads doing something on a dual core processor?
BigETI is offline   Reply With Quote
Old 27/07/2013, 01:43 AM   #18
Lorenc_
High-roller
 
Lorenc_'s Avatar
 
Join Date: Jan 2010
Location: Australia
Posts: 3,793
Reputation: 1179
Default Re: Bcrypt

Finally! Well done!

Is it possible for a non-threaded version? Thanks.
__________________
Join the best Cops And Robbers in SA-MP, today. svr.sfcnr.com:7777

Lorenc_ is offline   Reply With Quote
Old 27/07/2013, 07:51 AM   #19
Dan..
Gangsta
 
Join Date: Jun 2012
Location: Galati, Romania
Posts: 521
Reputation: 122
Default Re: Bcrypt

Quote:
Originally Posted by ****** View Post
I would actually disagree with that. Creating threads does have a lot of overhead, but if you can create a pool of workers somewhat equal to the virtual cores on your machine then you will improve performance with more than 2.
Creating threads doesn't have a lot of overhead, but creating a new thread, executing it parallelly, collecting the result (there is a mutex that will waste a little more), sending it back to the main thread, killing the thread does.
__________________
I'm no longer visiting these forums. BlueG, you can suck my dick.
Dan.. is offline   Reply With Quote
Old 28/07/2013, 12:10 PM   #20
Johnson_boy
Huge Clucker
 
Join Date: Mar 2011
Location: Finland
Posts: 215
Reputation: 80
Default Re: Bcrypt

Quote:
Originally Posted by Lorenc_ View Post
Finally! Well done!

Is it possible for a non-threaded version? Thanks.
It's possible, but does not really make sense. If everything is executed in one thread, the server will have to wait while the hash is calculated, which will be noticed as lag by the players. Calculating a bcrypt hash takes a significant amount of time, about 0.5 seconds, when a work factor of appropriate magnitude is used.
Johnson_boy is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



All times are GMT. The time now is 09:55 PM.


Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.