Thread synchronization in VB

[pendell]

Gentles,

My company has a legacy VB 6 program that receives information via TAPI -- the telephony system. They want it to receive information from network sockets as well.

I am the luckless Java/C++ guy who has been asked to dig the source code out of storage and try to make this work. After all, I know how to program computers so I must know VB, right?

So I've been looking at your excellent FAQS, and I think I've got a good starting point for what needs to be done WRT network programming, as well as TCP/UDP connection.

But one thing puzzles me.

In the examples I have looked at, I haven't seen any shared memory/concurrency/thread synchronization examples.

In the environment I'm from, sockets or other artifacts have separate threads listening on them, which populate a shared message queue, which is then consumed by another thread responsible for business logic. This shared memory artifact requires synchronization tools, such as semaphores, monitors, Java's "synchronized" block, etc.

I haven't encountered any such examples in VB 6.

Is it simply because the examples in question are simple, and do not include such concerns? If so, where can I look for that information?

Or am I completely mis-understanding the nature of VB6? Is this all handled automatically by the underlying software? Or do we not have those tools in VB6? Or do we have them, but it's inadvisable to try to use them?

Yes, I know we should be using VB .NET. That is a crusade I am waging. But for the moment, I have to work with the tools available.

Respectfully,

Brian P.

[RhinoBull]

Welcome to Forums, pendel!

If I understood you correctly... VB6 natively does not support multithreading - the closest way possible is the ActiveX.exe. Have a look at Woksa's sample project.
Someone may suggest to use winsock/timer "combo" directly in your project but I don't think it will be as robust.

[dilettante]

A normal VB6 program's architecture hides most of the details of multithreading beneath an asynchronous event processing paradigm.

Your listener/worker threads are implemented within component libraries written by professionals that a VB6 programmer uses as building blocks.

The code you write in VB6 itself consists entirely of event handlers implementing business logic responding to messages arriving in the message queue. This logic normally runs on a single thread, though there are mechanisms for dispatching work to thread-pooled or thread-per-instance objects. The programmer never needs to write synchronization logic unless they hack around and break the VB paradigm.


Remember that this development system was originally meant for producing monolithic CRUD and reporting applications through RAD processes. The datastore was originally an embedded database (early MS Jet).

Later evolution made VB useful for creating 2-tiered applications using various client/server databases.

After that VB evolved so that it could be used to write front-end GUIs and middle-tier business objects backed by a data-tier.


The idea here was to get very high programmer productivity by forcibly keeping programmers from trying to reinvent the wheel or having to write and debug things like tricky synchronization logic.


People try to use it for all kinds of weird things now that fall far outside its intended range of application. They've actually been pretty clever about it, treating as a successor of compiled DOS Basic or a simple C compiler with Basic language syntax.

[pendell]

Rhinobull,

You have understood me correctly.

Thank you. This confirms my own research, done after I posted the question: That while it's technically possible to create a thread in VB6, there are no synchronization mechanisms for sharing information between threads. Rather, each thread has its own copy of memory that cannot be accessed by other objects outside the thread.

It is technically possible to do these things -- or so I'm told -- if you're willing to call the Win32 API or related calls, effectively dropping out of Visual Basic to do this work. But I have no interest in doing so.

ETA: And thank you as well, Dilettante, for further confirmation.

Respectfully,

Brian P.

[Doogle]

As RhinoBull says, multi-threading in VB doesn't work. However, Winsock (the VB implementation of Sockets) does work fully asynchronously and doesn't require timers etc. ie When something arrives an interrupt (Event) is raised, you process it and go back to where you were before. When you send something with Winsock it's put on the network immediately, and you can check when it's all been sent (ie put on the Network) with the SendComplete event. If you need to, you can implement an Application Protocol to confirm when a message has been recieved and successfully processed.

As with all IP processing you are responsible for buffering the data and determining when it's all arrived and so on. But what you have described ought to be managable by Winsock without any 'add ons' My guess is in much the same way that the TAPI processes have been implemented.

Naturally, it all depends upon the complexity of the appliction......

All IMHO, of course

[dilettante]

You're right Doogle. People from outside the VB world don't realize how cleverly the system was put together to isolate the programmer from a lot of gory details without limiting his ability to write powerful software. People on the inside sometimes frighten these outsiders off with the best of intentions.

[dilettante]

In case he comes back, there are existing TAPI and post-TAPI components available for doing what he wants:

Telephony Application Programming Interface Version 3.1

Real-time Communications (RTC) Client