Click here to Skip to main content
15,792,217 members

Pablo Aliskevicius - Professional Profile


LinkedIn      Blog RSS
Pablo writes code for a living, in C++, C#, and SQL.

To make all that work easier, he uses some C++ libraries: STL, ATL & WTL (to write Windows applications), and code generation.

Pablo was born in 1963, got married in 1998, and is the proud father of two wonderful girls.

Favorite quotes:
"Accident: An inevitable occurrence due to the action of immutable natural laws." (Ambrose Bierce, "The Devil's Dictionary", published in several newspapers between 1881 and 1906).
"You are to act in the light of experience as guided by intelligence" (Rex Stout, "In the Best Families", 1950).


Weekly Data. Recent events may not appear immediately. For information on Reputation please see the FAQ.


Members need to achieve at least one of the given member levels in the given reputation categories in order to perform a given action. For example, to store personal files in your account area you will need to achieve Platinum level in either the Author or Authority category. The "If Owner" column means that owners of an item automatically have the privilege. The member types column lists member types who gain the privilege regardless of their reputation level.

ActionAuthorAuthorityDebatorEditorEnquirerOrganiserParticipantIf OwnerMember Types
Have no restrictions on voting frequencysilversilversilversilver
Bypass spam checks when posting contentsilversilversilversilversilversilvergoldSubEditor, Mentor, Protector, Editor
Store personal files in your account areaplatinumplatinumSubEditor, Editor
Have live hyperlinks in your profilebronzebronzebronzebronzebronzebronzesilverSubEditor, Protector, Editor
Have the ability to include a biography in your profilebronzebronzebronzebronzebronzebronzesilverSubEditor, Protector, Editor
Edit a Question in Q&AsilversilversilversilverYesSubEditor, Protector, Editor
Edit an Answer in Q&AsilversilversilversilverYesSubEditor, Protector, Editor
Delete a Question in Q&AYesSubEditor, Protector, Editor
Delete an Answer in Q&AYesSubEditor, Protector, Editor
Report an ArticlesilversilversilversilverSubEditor, Mentor, Protector, Editor
Approve/Disapprove a pending ArticlegoldgoldgoldgoldSubEditor, Mentor, Protector, Editor
Edit other members' articlesSubEditor, Protector, Editor
Create an article without requiring moderationplatinumSubEditor, Mentor, Protector, Editor
Approve/Disapprove a pending QuestionProtector
Approve/Disapprove a pending AnswerProtector
Report a forum messagesilversilverbronzeProtector, Editor
Approve/Disapprove a pending Forum MessageProtector
Have the ability to send direct emails to members in the forumsProtector
Create a new tagsilversilversilversilver
Modify a tagsilversilversilversilver

Actions with a green tick can be performed by this member.

GeneralOn global pointers. Pin
Pablo Aliskevicius4-Apr-12 20:42
Pablo Aliskevicius4-Apr-12 20:42 
GeneralThe programmer as an artist Pin
Pablo Aliskevicius13-Sep-11 0:09
Pablo Aliskevicius13-Sep-11 0:09 
GeneralRe: The programmer as an artist Pin
Aniruddha Loya14-Nov-11 22:29
Aniruddha Loya14-Nov-11 22:29 
GeneralThere is no such thing as quick and dirty. Pin
Pablo Aliskevicius30-Mar-09 22:30
Pablo Aliskevicius30-Mar-09 22:30 
GeneralRe: There is no such thing as quick and dirty. Pin
ThatsAlok18-Jul-11 23:57
ThatsAlok18-Jul-11 23:57 
GeneralRe: There is no such thing as quick and dirty. Pin
Pablo Aliskevicius19-Jul-11 3:39
Pablo Aliskevicius19-Jul-11 3:39 
GeneralRe: There is no such thing as quick and dirty. Pin
ThatsAlok20-Jul-11 2:07
ThatsAlok20-Jul-11 2:07 
GeneralShame on me: a race condition.... Pin
Pablo Aliskevicius28-May-08 9:39
Pablo Aliskevicius28-May-08 9:39 
GeneralWhen multithreading is not an option... Pin
Pablo Aliskevicius19-Mar-07 11:18
Pablo Aliskevicius19-Mar-07 11:18 
GeneralMore on thread procedures... Pin
Pablo Aliskevicius13-Oct-06 4:36
Pablo Aliskevicius13-Oct-06 4:36 
General::PostThreadMessage. PinPopular
Pablo Aliskevicius11-Oct-06 9:05
Pablo Aliskevicius11-Oct-06 9:05 
Multi threading is anything but boring.

A few days ago, I was asked to improve the performance of a program, which reads a FOX Pro table, generates SQL INSERT commands, and executes them against a database.

The way to do it was clear: read in one thread, write on another. To spice things up, since inserting is much slower than reading (all that index updates, you know), three writer threads were matched to the reader.
The writers' thread procedure looked like this (pseudo-code):

<br />
DWORD WINAPI ThreadProc(LPVOID pX)<br />
{<br />
    // Cast passed pointer to what it really is.<br />
    // Initialize COM<br />
    // Generate message pump<br />
    ::PeekMessage(whatever);<br />
    // Connect to database<br />
    while (!done)<br />
    {<br />
        ::GetMessage(....)<br />
        switch(msg.uMsg)<br />
        {<br />
            case WM_COMMAND: // Cast LPARAM to pointer to a Job, execute that job.<br />
            break;<br />
            case WM_QUIT:<br />
            done = true;<br />
            break;  <br />
<br />
        }<br />
    }<br />
    SetEvent(reallyDone);<br />
    return 0;<br />
}<br />

Nice, right?
Tested it with 16K records: runs like the wind, results are fine.
64K records: still OK.
80K records: some start to get lost.

I've use ::PostThreadMessage() for quite some time: the caller allocates a Job, posts it to the queue, the worker thread pops it from the queue, executes it, and deletes it. All synchronization tasks are taken care of by the OS, which minimizes thread switches.

Well, you always have to read the fine print. And the fine print for ::PostThreadMessage() is that the queue size is 10,000 messages. That's a lot, if you have a few dozen long-running jobs (in the past, for me, that was the usual).

So, how could I handle it?

My first idea was the use of a 'thermostat'. An integer was interlock-incremented whenever a message was posted, and interlock-decremented whenever a job was executed, thus holding the count of messages in the queue.

The manager thread would test the queue size: if longer than 900 messages, it would Sleep for 50 milliseconds: if, after that, there were less than 1000 messages, it would try to post one (in a loop); if, after 5 tries the message was not posted yet, the job would be executed on the calling thread.

I didn't like it: whole lot of interlocking going on, and Sleep is by far not my favorite API.

Well, the bad news was as expected: performance went down by 30%, but still it was three times faster than the original program.
The good news: 80K records, and none got lost. 150K, and none got lost!

So I tried for 400K (the program should be able to send about a million): well, it got stuck after 215K. Playing with the thermostat settings helped a bit, but no cigar.

After a couple of hours, I gave up. Added std::queue<Job *> to the mix, managed synchronization with a critical section (which protected this queue), and performance went back to good. Private bytes and CPU usage were totally flat, up to 400K records.

The program was ripe for the QA department.

What did I learn?

::PostThreadMessage() is a nice tool, but it has some limitations. Its usage: when you have just a few 'big' jobs, and in a program which runs, does its thing and exits. For long-running programs, or programs which send to the worker threads a lot of small jobs, you're better off rolling your own queue.

And yet, multithreading, when you know how to do it, can be a great way to make an impression, and to become the star of your company parties.


General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.